Create lists, content types, fields etc. within a SharePoint 2013 app

Disclaimer: Just because I’m writing about apps, doesn’t mean I think everything in SP2013 should be developed as an app! I’m focusing on apps simply because it’s a deep area with lots to learn.

Recently I’ve been building a SharePoint 2013 app to help me learn the framework – specifically an on-premises app which has some SharePoint components, rather than a purely remote app. This series is based on some scenarios which I think are key building blocks for apps – for a given set of requirements, you’ll likely need to do one or more of these things. Frankly,you might need to do 100 other things too, but these are certainly common. Here’s a rough outline for the series (which I’ll probably tweak, and will definitely add to):

1. SharePoint 2013 apps – architecture, capability and UX considerations
2. Getting started – creating lists, content types, fields etc. within a SharePoint app (provisioning) [this article]
3. Working with data in the app web, and why you should
4. Access end-user data (in the host web) from a SharePoint 2013 app
5. Rolling out SharePoint 2013 apps to the enterprise - tenant scope and PowerShell installs
6. Azure is the new SharePoint ‘_layouts’ directory
7. “Host web apps” – provisioning files (e.g. master pages) to the host web
8. “Host web apps” – provisioning fields and content types
9. Deploying SP2013 provider-hosted apps/Remote Event Receivers to Azure Websites (for Office 365 apps)
10. Working with web parts within a SharePoint app

You’ll notice that I’m skipping setting up a SharePoint 2013 dev environment for developing apps. I think other folks have done a good job here – here are some good sources:

• How to: Set up an on-premises development environment for apps for SharePoint (MSDN)
• Setting up your App domain for SharePoint 2013 (Mirjam van Olst)

Before we start – understanding the ‘app web’ and security model

If you’re getting into developing apps for SharePoint, then I’m assuming you know something about the separation of apps and host webs. In a nutshell, apps are kept separate from ‘real’ end-user SharePoint sites – any lists and document libraries created by the app, any files and web pages, all live in a separate web application to the host site. When a user clicks on the app, they leave the host site behind and get redirected to a web which was created when the app was installed for this site. Effectively an ‘app web’ gets created for every site the app is installed to, in a structure which mirrors the host sites themselves.

Security is the primary driver behind this architecture – the app itself has Full Control over this specially-created site, but no rights (by default) to host sites. Clearly if a malicious app could delete end-user data, that would be A Very Bad Thing. Microsoft would not want that to happen, and so we have this separation. Additionally, it also serves to provide protection against cross-site scripting (IF the web application created for apps does not use the same domain or a subdomain – it should not), and allows SharePoint to identify the caller for Client Object Model calls.

UPDATE 17 Sept 2012: Actually there are circumstances where the developer *can* choose to have the lists/files/web pages etc. created in the host web rather than the app web. See the second half of the next article in this series Working with the app web, and why you should for discussion of this.

If you need more detail this host/app web split, then Ted Pattison has a nice post (in a great series) at SharePoint apps are isolated with respect to request processing and storage. You might not need to understand everything about this right now, but you shouldn’t ignore it.

Getting started– creating your first SharePoint-hosted app

Nothing too complex here – just fire up Visual Studio 2012 and create a project from the ‘App for SharePoint 2013’ project template:

You’ll then be asked to specify some settings for the app – here we need to tell Visual Studio which local site we’ll be developing against/deploying to, and that we are creating a SharePoint-hosted app:

The project is created, and you’ll see that a bunch of files are added automatically – this is effectively a “Hello World” sample which is useful to get you started. jQuery is referenced, a Default.aspx page is added to the app, and this references a CSS file (App.css) and a JavaScript file (App.js) – the JavaScript file has some CSOM code to fetch the current user’s name and put it in a DIV on the page:

If you hit F5 to deploy this, you’ll see that the result is a pretty empty page which shows your app’s title (not yet converted to a user-friendly name in my case), and after a second or so for the AJAX call to complete, shows your username:

At this point, it’s interesting to consider what this sample page does NOT have:

• Any form of left-navigation/quick launch
• Top navigation (although the more global strip in the chrome across the top exists)
• Breadcrumb (although note the single link back to the host web, ‘Team 2’)
• A Site Actions menu
• A link to a Site Contents page (N.B. this page cannot be viewed in an app – if you try, you’ll get something like “The endpoint /team2/cobsharepointappsmyfirstapp/_layouts/15/viewlsts.aspx is not accessible in the context of a SharePoint App.”

So, it’s a pretty “bare bones” starting point. Now let’s take this towards something a bit more like a real-life app.

The concept - my "learner” time-recording sample app

To help us understand the app framework, let’s say we have to build some kind of time-recording app. Lots of us work in utilization-focused consulting organisations, so the concept of a timesheet is usually all too familiar.  The app I’m going to show won’t win any awards for functionality or design – and it definitely doesn’t provide enough end-user value to consider submitting it to the app store :) It’s purely to help me learn about apps, and I’d rather explore different areas even if the design is impractical or doesn’t really make sense.

Here’s what it currently looks like, though I’ll probably add bits to it over the course of this article series:

 

 

App implementation

In terms of artifacts, some fundamental pieces of the app include:

• Projects list
• Logged time list
  • Uses TrackedTime content type – this defines 4 fields, including a lookup to Projects and a Person/Group field for employee
• Utilisation targets (per employee) list
• Default page
• “My time summary” page – this is effectively a navigation-free version of Default.aspx
• App part (ClientWebPart) to display “My time summary” page in host web

As I discussed in SharePoint 2013 apps – architecture, capability and UX considerations, it’s important to understand (or remember) is that with a couple of exceptions, a SharePoint-hosted app can only provision things into the automatically-created “app web”. This lives under the “apps” web application which must be created in an on-premises scenario. The diagram below tries to illustrate the breakdown between host site and app web – importantly, note that the “Utilisation targets” list in the host web was manually created outside of the app – purely because I wanted my app to include the scenario of working with data in the host web. In other words, you cannot usually get your app to provision a list in the host web. The only exception to this is if the app has Full Control to the host web, and some CSOM code runs to create this list - see Working with the app web, and why you should for discussion of this scenario. Note you can click on the image below to see a larger version:

 

Provisioning lists, content types, site columns etc. within a SharePoint-hosted app

So the good news here is that there isn’t a huge amount of change if you’ve done these commonplace tasks in SharePoint 2010/Visual Studio 2010. That said, there are a couple of things which can throw you off track if you weren’t expecting them. The main difference of course, is that you’re not creating things in the actual site itself – and in the initial stages it’s tricky to know whether your artifacts are being provisioning successfully.

I’m not going to show the beginning-to-end process of deploying the above artifacts, but let’s look the outline. Depending on how you like to work, you might want to start with things like:

• Rename ‘Feature1’ which was automatically added to your VS project, add a description etc.
• Create some folders in your project if you prefer more structure than the default

Creating fields and content types

I created a TrackedTime content type with 4 fields. For my Projects list I didn’t actually define a custom content type – a simple list purely with a Title field sufficed.

1. Right-click on the project in Solution Explorer, then select Add > New Item…
2. From the Office/SharePoint category, select Site Column and name the item accordingly:
   
    
   
3. Visual Studio will add some default XML for you. To define the 4 fields needed by my TrackedTime content type, I ended up with the following XML – note the lookup to the Projects list which is accomplished purely with declarative XML courtesy of the “List=’Lists/Projects’” on the 3rd field:

      1: <?xml version="1.0" encoding="utf-8"?>

      2: <Elements xmlns="http://schemas.microsoft.com/sharepoint/">

      3:   <Field

      4:        ID="{ac8a5625-8769-4ed5-bfce-5ced1bfda792}"

      5:        Name="TimeTrackingEmployee"

      6:        DisplayName="Employee"

      7:        Type="User"

      8:        List="UserInfo"

      9:        Required="TRUE"

     10:        ShowField="ImnName" 

     11:        UserSelectionMode="PeopleOnly"

     12:        UserSelectionScope="0" 

     13:        Group="COB time-tracking site columns" />

     14:   <Field

     15:        ID="{CA358CA2-ED71-49D9-A05F-51C92B504062}"

     16:        Name="TimeTrackingDate"

     17:        DisplayName="Date"

     18:        Type="DateTime"

     19:        Format="DateOnly"

     20:        Required="TRUE"

     21:        Group="COB time-tracking site columns" />

     22:   <Field

     23:        ID="{ED1B7F0F-CACA-45A1-A0DD-8D0E6E604C5C}"

     24:        Name="TimeTrackingProjectName"

     25:        DisplayName="Project/task"

     26:        Type="Lookup"

     27:        List="Lists/Projects"

     28:        ShowField="Title"

     29:        Required="TRUE"

     30:        Group="COB time-tracking site columns" />

     31:   <Field

     32:        ID="{62D635BE-6481-4E2A-A6B6-4CDA40EAFB00}"

     33:        Name="TimeTrackingDuration"

     34:        DisplayName="Duration (hours)"

     35:        Type="Number"

     36:        Decimals="1"

     37:        Required="TRUE"

     38:        Group="COB time-tracking site columns" />

     39: </Elements>

4. To make a content type using these fields, I then selected Add > New Item… and selected Content Type and named appropriately:
   
   
   
    
5. The next step is to add the fields we created to the content type. Visual Studio 2012 has a cool new Content Type Designer which appears here – simply start typing the name of the field, and VS scans fields from the SharePoint site it is connected to PLUS fields defined in the VS solution:
   
   
   Any fields added here will then be referenced as FieldRef elements in the content type XML behind the designer.
   
   
6. Now we’re ready to provision a list based on this content type/set of fields. The initial steps are the same as you might be used to, but again we have a handy VS designer to help. Firstly we need to do an Add > New Item… and select List, then name appropriately:
   
   
    
7. Now we see the new List Designer – if we wanted to add fields directly to the list rather than add a content type, we could use the main area of the Columns tab, but usually we’ll want to hit the ‘Content Types’ button:
    
8. In here, we can type the name of a content type already in the SharePoint site or within our VS solution:
   
   
   
9. Usually we’d also want to delete the Item and Folder content types, to leave just our custom content type with the fields:
   
   
   
10. The ‘Views’ tab within the list designer can then be used to add any custom views – in my case, I added one called ‘By employee’:
    
     
    N.B.  Unfortunately the designer doesn’t support all the things you might want to do, so in my case I had edit the XML by hand (the horror!) to actually implement the grouping. Still, this is all WAY better than we had before with SharePoint 2010 development.
    
    
11. The final step is to ensure we’re happy with the top-level properties for the list, such as the title and URL. Take note of the URL the list will be provisioned to, you’ll need this soon:
    
     
12. If we’re happy with the list, we can then test our app by hitting F5. When we click through to the app from the Site Contents page, we’ll be back here:
    
    
    At this point, the big question is…

“Where’s my list?!”

Of course, since there’s no default navigation in an app, it’s not immediately obvious if the list has been provisioned or not. However, if you’ve done the right things you’ll find your list is actually there. It’s tempting of course to try typing /_layouts/viewlsts.aspx in the URL bar, but as I mentioned earlier that’s not a page which can be used in an app.

Instead, just paste the URL of the list directly into the browser address bar after the app URL and you should be taken to your newly-provisioned list:

If you do not wish the list to be “hidden” (i.e. you want users to use it as a regular list), your next step will be to think about navigation – and what you’ll add to that default page so that users can get to the list.

Summary

So we now have a list which our app could use to store data. We could either allow end-users to access the list through the UI, use CSOM to read/write to it, or a combination of both. If you’ve created lists, content types etc. from Visual Studio in SharePoint 2010, you should find the process almost exactly the same – the main differences are the new VS designers and the fact that we’re provisioning to the app web.

Next time we’ll look at working with data in the app web.

SharePoint 2013 apps – architecture, capability and UX considerations

UPDATE: this article turned into part 1 of a series on SharePoint apps - here's the table of contents:

1. SharePoint 2013 apps – architecture, capability and UX considerations [this article]
2. Getting started – creating lists, content types, fields etc. within a SharePoint app (provisioning)
3. Working with data in the app web, and why you should
4. Access end-user data (in the host web) from a SharePoint 2013 app
5. Rolling out SharePoint 2013 apps to the enterprise - tenant scope and PowerShell installs
6. Azure is the new SharePoint ‘_layouts’ directory
7. “Host web apps” – provisioning files (e.g. master pages) to the host web
8. “Host web apps” – provisioning fields and content types
9. Deploying SP2013 provider-hosted apps/Remote Event Receivers to Azure Websites (for Office 365 apps)
10. Working with web parts within a SharePoint app

SharePoint 2013 brings the “app” framework and the Office/SharePoint app store - and whenever a new version of SharePoint brings a new development approach, developers often leap on it as some internal challenge which they have to conquer (sometimes at the expense of actual client requirements). Other bloggers have published similar “when to build apps” articles as this one, but I noticed I’d perhaps come at it from a different angle. Specifically, after I had built my first “hello world” SharePoint 2013 app, the internal question I wanted to prepare myself for was:

“Should I develop the feature my client is asking for as an app? The client has no strong opinions on the matter (they do not know the app framework well) and are looking for guidance from me/my company.”

Initially I wanted to focus on the user experience of using a piece of functionality developed as an app. Most folks who have had direct experience of SharePoint users would agree this is definitely a key consideration. So, the last half of this article is dedicated to UX.  However, it’s fair to say that there are potentially bigger aspects to think about too – after all, it might not even be possible to create the desired functionality as an app. So let’s start with app architecture and capability considerations.
One final thing - to frame this discussion, consider that Microsoft say “develop an app where you can” (although their motives may not be the same as you/your client – I’ll come back to this point in the closing summary).
Disclaimer July 31 2012 – SharePoint 2013 is in preview at this stage, so some specifics and user experiences may change slightly between now and release time.

Architecture considerations

Guided by MSDN (see reading list at the end of this article), when considering app development my summarized checklist here would be:

• From the 3 hosting options, which are available to me?
  • SharePoint-hosted – [this one is a given since you have a SharePoint environment]
  • Externally hosted (to the SharePoint farm)
    • Do we have some non-SharePoint servers which could host this app, or could some be created?
    • Assuming resilience is required, is there a load-balancing/failover solution in place?
    • How much effort would be required to give them the same business continuity (DR, backup/restore) as the SharePoint servers?
    • Is capacity planning required around processing power, memory usage, network latency/throughput, disk performance and data storage?
    • If we want do develop in .Net, do they run IIS?
    • If the app(s) need to store data, where would this be?
  • Auto-hosted (SharePoint Online + Azure)
    • Does the client’s web application where the app(s) would be deployed run in SharePoint Online (since Azure auto-hosting is only available to apps deployed to SharePoint Online)?
    • Does the client have an Azure subscription?
    • Has Azure capacity planning been done? Is any more CPU/memory/disk needed for the new app(s)?
    • Can we accurately estimate how much the Azure costs will be each month?
    • Do we have the skills to develop in Azure, or can the devs learn on the project?
• Is a combined app hosting approach appropriate? (e.g. some SharePoint artifacts, and some external to SharePoint)
• Does the selected app hosting model fit with business and I.T. strategy?

With these points in mind, I wonder if purely SharePoint-hosted apps could be easier to achieve than externally-hosted apps for some non-Office 365/SPO clients. I’ve seen some organizations take months to provision servers, so even in this virtualized world standing up some .Net servers to support a SharePoint app might not be the easiest thing. But, SharePoint-hosted apps do not have the same capability as apps with an external component, so let’s think about that for a second..

Capability considerations

The key question here is:- can the functionality be built using the app hosting options I have available to me? Consider the following:

• An app cannot have any server-side SharePoint code – all code must use client APIs such as CSOM, the REST API and web services
• By default, any SharePoint artifacts provisioned (lists, web parts, content types, site columns, master pages, content pages, other files) do not get provisioned in the site end user browses –  rather, they get created in a special “app web” on a special URL which is isolated from the original SharePoint web. This could be particularly relevant if, for example, if there needed to be some kind of aggregation or link between user content and content related to the app.
• Unless the app requests special permissions (which must be agreed to at install time), an app does not have permission to talk to the parent site or site collection – furthermore, there is no permission possible which allows the client APIs talk to the parent web application or farm. [See Working with the app web, and why you should for more info on these points.]
• Deep changes to the user site are not possible with an app – site definitions, branding, themes, most types of ribbon customization or link changes which would require a CustomAction are examples
• Timer jobs are not possible within an app – within a SharePoint-hosted app, it’s difficult to see how any “scheduled processing” could ever be implemented. This is a key difference to an Azure or externally-hosted app (or single app component), which could either use the Azure Service Bus or even a scheduled task on a non-SharePoint server which calls into SharePoint using a client API
• Custom field types are not possible within an app

User experience considerations

• How will users obtain the app?
  • Will it be rolled out to all/selected sites automatically?
  • Will site owners/users with Full Control be responsible for obtaining the app from the App Catalog? (for this discussion we’ll assume the app will not be pushed to the public store)
• For apps not automatically rolled out, could the app’s trust/capability requirements alarm some site owners and cause them to cancel app installation? (see later screenshots). If we haven’t educated them about this process, could it result in helpdesk calls?
• Which of the user experience options will the app make use of?
  • Navigation to separate SharePoint app web?
  • Navigation to external site which uses the chrome control? (note that this is only applicable if any app UI components are hosted externally to SharePoint)
  • App parts (ClientWebPart) which use an IFrame to bring app content into the host web ?
  • Navigation through a list item’s dropdown (Edit Control Block [ECB]) links, ribbon customizations
• Does the separation of app and other site content work?
  • Could users be confused that (e.g.) a document library provisioned by your app cannot be found next to their other document libraries? (Remember that to find the app’s document library, they have to “enter” the app and be taken to the separate app web which contains it’s data/artifacts.)

With the above points in mind, let’s take a look at the user experience for site owners and end users.

The site owner experience – adding a SharePoint app

Apps can only be added by users with Full Control permission to the site (typically site owners only), so this process only applies to them. We’ll show obtaining an app from the App Catalog here, but remember site owners may also be able to purchase from the public store, if so configured.

1. A site owner would navigate to the app “area” (‘Your Apps’) which shows apps published to the App Catalog and has a link to the public SharePoint Store. A site owner can get there either by using the link on the Site Actions menu:
   
   
   ..or the link in the Site Contents page:
   
   
2. In ‘Your Apps’, the site owner would then find an app..
   
    
3. .. and optionally click the ‘App Details’ link to see more about the app. As you might expect, this page has some blurb from the publisher and some screenshots of the app in action:
   
    
4. If the site owner is happy with this, they can click the ‘Add it’ button – at this point, they are presented with some permission requirements the app has. This could be to SharePoint content such as lists/libraries, but also other items such as calling into a service application. Remember that an app can run with different permission levels than the actual person using it (e.g. an app could be allowed to delete documents where the user cannot directly), and this step ensures someone responsible for the site grants the required access. This is known as an app permission request.
   
   
   
   (As a sidenote, it will be more normal to see an app requesting to work with a specific list, rather than the site owner selecting a list from a dropdown – the image above shows the result of me specifying that the app requires ‘Manage list’ rights, but not specifying a particular list that this applies to).
   
5. If the permission request is granted, then the app is added to the site and is then accessible from the ‘Site Contents’ area:
   
   

At this point, the app is now usable by regular site users.

The end-user experience – using an app

Actually you just saw it. For ‘full page’ apps, users will access apps from the ‘Site Contents’ area as shown in the last image. Here they can also find other apps, lists, document libraries and so on. When the app icon is clicked, the user will be redirected to the start page for the app (as defined in the ‘StartPage’ property in AppManifest.xml). In the SharePoint-hosted example I showed in my last post, this could be a page provisioned to the app web:
 
Regardless of where the user goes within the app, the header maintains a simple breadcrumb link back to the host web (where the app was accessed from).
Note that apps can also be surfaced in other ways than the full page model – if a web part is effectively all that’s needed, then SharePoint 2013 provides ‘app parts’ (aka ClientWebPart) which is an IFrame-wrapper to bring the UI of an app into the host web. In the case of a SharePoint-hosted app, this could be a page provisioned into the app web (as shown above), or if the app has external components it could be a page hosted on some external servers.

The site owner experience – adding from the public SharePoint Store

In case you’re wondering, the experience of using the public app store is not hugely dissimilar to using the internal App Catalog. Some bits are not live yet (e.g. the financial transaction bit), but effectively there’s a big categorized list of apps to pick from:

The site owner experience – where app feature/capability requirements are not met

Regardless of where the app comes from, in addition to permission requests (which the site owner must acknowledge when trusting the app during installation), apps can also specify prerequisites in terms of SharePoint features. After all, if an app is dependent on say, the SharePoint 2013 social features, it would clearly fall over in a heap if that service isn’t available in an environment where the app is being installed. So, the app framework does not allow installation of an app if these prerequisites are not met – the site owner will see a message stating that the app cannot be added:

In this scenario, the ‘app details’ page lists the reasons why the app cannot be added:


The important thing here though is that there is no magic - SharePoint is not doing some inspection of every line of code behind the app to work out what it needs. Instead, it’s up to the app developer to specify all prerequisites (including permissions requests) before the app is packaged – this info goes into the AppManifest.xml file, but there is a handy designer in Visual Studio 2013:

Other user experiences e.g. SharePoint administrator

In addition to the site owner ‘app install’ experience and the end-user ‘app usage’ experience, there are other stakeholders to consider too. Administrators will want to know things like:

• Which apps are in use where
• If any apps are currently experiencing problems
• Which apps in the public SharePoint Store are the top requested apps – this applies in the scenario where site owners are not allowed to directly obtain apps from the public SharePoint store, but are allowed to log an ‘app request’

A series of screens in Central Administration supports these administrator needs, but I’ll save that for another post.

Summary

The SharePoint 2013 app framework is a fairly radical departure in the world of SharePoint development, and when formulating SharePoint strategy it’s important to understand when apps are appropriate and when they are not. A piece of functionality can now effectively be rolled out to SharePoint in three different ways:

• Farm solution
• Sandboxed solution
• SharePoint app (which as discussed above, could be a purely SharePoint-hosted app, an app hosted on non-SharePoint hardware [possibly by a vendor] or an Azure auto-provisioned app – my intro post also has more details)

Microsoft guidance says “develop an app wherever you can”, but consider that they may not have the same goals as your project/environment. Personally, I buy into the idea that a key MS driver for apps was to reduce SharePoint upgrade complexity and therefore maintain the license income stream. If you have evaluated your development/customization strategy and are of the view that upgrade to whatever the next version of SharePoint will be is entirely manageable, then I wouldn’t necessarily conclude that apps are in any way mandatory.
In that case, the question might then be “do the semantics and user experience of the app model give me something over and above other customization approaches?”. Some examples of this could be the App Catalog experience, or perhaps keeping in line with the way other customizations have been developed – either way, there might be fewer things to consider if you aren’t constrained by upgrade/architecture concerns.

Further reading

• MSDN: Apps for SharePoint compared with SharePoint solutions
• MSDN: Hosting options for apps for SharePoint
• MSDN: Apps for SharePoint UX design guidelines

SharePoint 2013 – my view on what’s new (particularly for developers)

So the SharePoint 2013 (previously known as ‘SharePoint 15’, the internal name) public beta is finally here. And that means that MVPs, TAP participants and other folks with early access are no longer bound by their non-disclosure agreements and can now talk about the product publicly. No doubt there will be a flurry of blog posts, but I wanted to write up my thoughts on what has struck a chord with me in the next version – partly because I have friends and colleagues who might look to me for this information, but mainly because it helps me crystallize my thinking on some of the new aspects. This started as a “developer perspective” article, but hopefully also gives a sense of what the new version brings for everyone.

If you’re a technical person, my view is that developers have a much bigger learning curve than IT Pros in this release. I might get flamed for that, and certainly IT Pros who need to deal with very large scale or need to know low-level detail on infrastructure topics might disagree, but that’s my view and I’m sticking to it :)

So this post represents my list – not in any order of importance.

Social

So it’s pretty interesting in the light of the Yammer acquisition, but yes, mature social capabilities are actually native in SharePoint 2013. Of course, they’re not quite the full hit that Yammer and Newsgator are, but my guess would be that the core SharePoint functionality will now meet many folks’ requirements – for the current generation of social intranets at least. I saw Steve Ballmer’s comments about the viral Yammer model too, but frankly I have to think that a big driver for the acquisition was to remove the “compete” element and bring Yammer into the fold.

The newsfeed (as it is now referred to - no longer “activity feed”) is much richer, and supports many of the enhancements I helped build for a client running SharePoint 2010 (see my post Extending SharePoint 2010 social capabilities). The newsfeed is now fully “two-way”, meaning items can be commented on, liked, and so on – so it’s a now a full Facebook-style feed:

As you might be able to tell from the image, some other capabilities include:

• @mentions
• #hashtags
  • These are searchable, and can be followed. Effectively the new hashtag bit has been merged with the existing SP2010 functionality of being able to follow a Managed Metadata tag.
• Ability to ‘follow’ a site or specific documents
  • This is very similar to the ‘subscriptions’ feature we built for SP2010. Effectively, you’ll see updates about this content (site or document) in your newsfeed
• Groups:
  • In addition to posting to everyone, I can opt to post only to the members of a specific team site – which could be a specific community with the company
• Ability to post links and pictures (with thumbnails automatically generated/used in the feed)
• Document/media preview from within the feed
  • No need to open a new window or be taken out of context to get a feel for the document/video/whatever
• Autocomplete:
  • The UI feels highly-usable – when I type @ to get a person’s name, or # for a hashtag, I get an autocomplete box which gives me categorized suggestions. In the case of an @mention, it initially gives me only people I’m following (left image), but as I type more and no results are found, it expands the search to all people (right image):
    
    

There is also a ‘team’ newsfeed for keeping up with what’s happening in a particular team site. So effectively SharePoint 2013 has just about all of the social features (and a couple more) we built for one of my old projects (see Extending SharePoint 2010 social features). I’m happy to see that the feature set looks good.

As I’ve predicted before, the API has been substantially re-engineered and a lot of the cruft I talked about in my “how we did it” post has gone away. You’ll see an option in Central Admin (in My Site settings within the UPA) to enable ‘SharePoint 2010 activity migration’.

Everything is an app

Certainly an interesting move on Microsoft’s part - but now if you create a couple of lists in SharePoint, in the SharePoint UI that’s “an app”. I can understand where Microsoft are coming from – not every new user understands what a SharePoint list, or a view, or a content type gives them, but frankly even my parents know what an “app” is. Still, there will be a level of confusion for users familiar with earlier versions – and folks may need some hand-holding around this. But when you think about the future and the next 2 versions of SharePoint (e.g. to “SharePoint 2019”), maybe it’s a good thing and these are concepts which should be switched earlier rather than later.

Of course, developers can create custom apps – that’s really the main point here, and it’s important since some of the challenges around getting code into an enterprise environment have arguably been addressed (more on this later). Here’s what the experience can look like – the site owner can install an app from the ‘Your Apps’ area:

From then on, Joe User can access the app from the All Site Content page:

With apps that give a full page experience, when he/she clicks on the app, they get taken to a completely different location which has a link back to the site which hosts the app. This is effectively the start page for the app:

App marketplace – plus remote apps

The big news is SharePoint finally gets an “app store”, meaning it’s far easier to add small solutions to SharePoint which fulfil a particular need (e.g. a timesheeting app, some social extensions, whatever). Given the success of this model in the consumer phone space, and it’s integration into Windows 8, it would have been bizarre for SharePoint 2013 not to have this also. It’s pretty revolutionary, since several things come together to make it much easier to get a 3rd party customization onto a SharePoint environment – whether the person trying to acquire the app is a team site owner somewhere, or the core SharePoint admin team:

• No need to have server administrators be involved with deployment/activation
• Integrated payment/procurement:
  • Got budget? Well if the facility is enabled by server administrators, all you might need is a credit card! Of course, more streamlined payment options (e.g. set up company account details, pay with that) are also possible, though management teams everywhere will be pleased to hear there are a number of governance controls in this area
• Regulated (by Microsoft) marketplace:
  • In the same way phone apps have to go through a certification process (involving checks on performance, legality, use of user interface controls etc.), the same will apply to SharePoint apps. It only gets into the public marketplace if all those boxes are checked, and many of the checks are performed by humans
• Corporate marketplace option:
  • In addition to the public marketplace, SharePoint 2013 provides a framework to have a corporate marketplace – in other words, an internal app catalog where only apps approved for use within the organization are added. Whoever owns the SharePoint platform controls whether the public and/or corporate marketplace are enabled. In the case of SharePoint Online, this is decided on a tenant-by-tenant basis
• App requests:
  • When governance controls are enabled, SharePoint provides a mechanism for end-users to “log a request” for a certain application from the public marketplace. Administrators can then track which apps are commonly requested, perform some internal validation, and then make them available in a controlled way.
• Safety:
  • There’s no point in having apps if they can cause harm to the SharePoint environment. Any individual ‘rogue’ app should not compromise the SharePoint environment as a whole. Of course, Microsoft introduced support for this with sandbox solutions, and it was just strange that the app marketplace piece didn’t come with it – but still, the foundations were laid. The big issue of course, was that sandbox solutions were/are intentionally limited in their capability (to support the safety aspect), and developers constantly hit the limiter in terms of what they could implement. To a large extent, Microsoft have removed these constraints, in quite an innovative way – I discuss this lower down in the ‘App hosting options’ section
• Upgrade framework:
  • Just in the same way we’re now used to updates to apps on our phone being pushed out by the vendor (and having the choice of whether we apply the update or not), a similar framework exists for SharePoint apps. This is great news for both users and vendors – it can mean quicker development cycles, a more efficient way of rolling out bug fixes and enhancements (e.g. it’s turns into at least 50% push, as opposed to 100% pull)

Needless to say, no doubt many vendors and developers with product ideas have been (or are about to start) scrambling to work out how they can leverage this. Of course, the marketplace won’t be empty during the beta phase – big name product vendors will have worked with Microsoft on the ISV TAP program. After all, an empty marketplace isn’t in anyone’s interest.

App hosting options – including remote apps with OAuth

So, I mentioned that many of the constraints around sandbox solutions have been removed in SharePoint 2013. Here’s how – apps can now run separately from the SharePoint environment itself. So if you have a need to run code which does some heavy processing (which could be shut down by SharePoint because it’s using too much CPU/memory/disk IO), then run it on a non-SharePoint server. In other words, take the problem outside of the SharePoint equation and deal with it there – the SharePoint admins (who might be Microsoft if you’re a SharePoint Online customer) are happy because the SharePoint performance/uptime is assured, and the developers (or the vendor selling the product) are now happy because they have a solution to the constraints of the sandbox. This means you can effectively build anything and target the sandbox or O365 – you just have to provide the resources (e.g. web hosting, processing power and if needed, data storage) elsewhere. This external “engine” can then talk to SharePoint (e.g. to read and modify data) using the client APIs such as CSOM and REST – these are *much* more capable now. OAuth is used for authentication, whereby the external app is granted a token to access a particular SharePoint site for a specified duration. Here are the top-level options:

• Remote - Azure
  • A lot of work has gone into enabling this. This is known as an Azure auto-provisioned app, and is integrated into the app deployment process – the developer/vendor can ensure that any “external to SharePoint” infrastructure is created on Azure as the app is deployed in SharePoint. This could include a SQL Azure instance to store data (so in the sandbox we’re no longer constrained by having to store data in SharePoint lists within the site collection), and Azure processing capability to do any heavy-lifting. Of course, this needs to be scaled appropriately for the app to work well, but it does work well as far as SharePoint is concerned.
• Remote - Developer-hosted
  • In this context, “developer-hosted” means “whoever is building the app supplies the hosting/infrastructure”. You don’t have to use Azure for any external portions of an app. In fact. you can use anything – another SharePoint farm, some other servers you have running IIS and SQL, Amazon Web Services, and more. By that, I mean this separation brings some interesting possibilities – since SharePoint doesn’t care about the processing that goes on here so long as you call into it using the client APIs, it’s effectively technology-agnostic. You could implement this part on a LAMP stack (Linux, Apache, MySQL, PHP) for all SharePoint cares – I nearly fell off my chair the first time I heard this! I’m not saying that particular aspect is hugely interesting to me personally – though it could certainly be relevant to product vendors, hosters or an organization with dev teams with different skills – but I do find it interesting that things aren’t restricted to IIS. And of course it does illustrate the separation of SharePoint and the remote piece of a remote app.
• On-premise - SharePoint-hosted
  • If you don’t need any external processing/data storage, then an app can be purely SharePoint-hosted. Notably, this is not a sandboxed solution – that model still exists, but this is something different. Server-side code is *not* allowed in a SharePoint-hosted app, so all SharePoint code is CSOM or REST (in addition to the HTML, CSS and JavaScript elements). What’s really important to understand about this model is that any SharePoint artifacts required by the app (e.g. pages, lists, content types, and so on) do not live in the actual site collection where the app is installed – rather, they get created in a special “app web” on a separate web application which is isolated from the site where the app is installed. Visual Studio 2012 with SharePoint dev tools understands this architecture when you deploy and test your app.

Note that SharePoint gives support for extending the branding of the hosting site into the app site (remember, even if it is hosted in the same SharePoint farm, it is still a separate web application/site collection).

Of course, we still have the traditional development models too. So if you’re asked to build a customization in SharePoint and you can deploy code to the farm, you could potentially choose from:

• Farm solution
• Sandbox solution
• SharePoint-hosted app

You’d have to decide whether your solution can be built using an app (i.e. whether the client APIs do what you need), and whether the app model is giving you anything (i.e. should users acquire the app from the marketplace).

Enhanced client APIs

No doubt partly to support apps, the client APIs have been given some love and are much extended. The Client Object Model (CSOM) has many new capabilities, and a new OData/REST API is introduced. My understanding is that both have the same capabilities, but the different programming styles are meant to provide choice – so if you’re coding in JavaScript or Silverlight you’d probably use CSOM, but if you’re talking to SharePoint from another platform (e.g. mobile app) then the REST API would be convenient. The early documentation listed the following as capabilities:

• Existing CSOM capabilities, plus:
• User Profiles
• Search
• Taxonomy
• Feeds
• Publishing
• Sharing
• Workflow
• IRM
• Analytics
• Business data
• ...and more

Note that the new REST API is known as _api since it can be accessed using the format http://somesite/_api/Web/title (with that example returning the title of the root web).

Use of .NET 4.5, but no MVC (within SharePoint at least)

Yes, of course the latest SharePoint is using the latest version of .NET. So we get a new GAC, new language features (e.g. web API, await/async, new HttpClient class etc.) and Visual Studio workflows are simpler, but the bigger impact is that if your code has to target both SharePoint 2010 and 2013, then you have some things to deal with (like avoiding the new language features in your codebase for one). If you follow developments outside of SharePoint in the wider ASP.Net world, it’s interesting that there is no option for using MVC and that a custom SharePoint page will continue to use the WebForms model – meaning Viewstate, postbacks for click events of .NET controls and so on. SharePoint developers the world over probably breathe a sigh of relief of not having to learn a new paradigm on top of a new product, but then pause to think if that’s ultimately a good thing. I don’t think it is personally. If you care that much, there *are* in fact options for surfacing MVC pages within SharePoint 15, but only in SharePoint ‘remote apps’ – and that stuff is far bigger for SharePoint than MVC vs. WebForms.

Use of Metro styling

Some new UI paradigms to learn, but on the plus side even I can style some colored blocks :)

Search-driven content

A capability some other CMS have, which I’ve wanted to see in SharePoint publishing sites for a long time, is the idea that a piece of content can effectively be surfaced in different locations (possibly with different branding/surrounding content), despite the fact that it is really just one piece of content. This content could be edited in one location. I might be showing my age here, but Content Management Server 2001/2002 kind of had this with connected postings, so it was annoying that nothing like it existed in the product for so long.

In SP2013, search is used to deliver this. That makes sense because search has long been the only way to “see past” the site collection boundary in SharePoint, and so this facilitates content sharing across site collections and web applications. You’ll find a new category of web parts called ‘Search-driven content’ – the web parts in here are all pre-configured variants of the Content by Search Web Part (e.g. “Items Matching a Tag”). The base Content Search web part can be found in the Content Rollup category. This is like a Content by Query Web Part on steroids, and using search:

Along similar lines,  any list/library in SharePoint can be nominated as a ‘catalog’ and then shared across site collections. This is part of the ‘Cross-Site Collection Publishing’ Feature and is also search-powered.

Skydrive Pro - Dropbox/Skydrive-like sync to PC, and simple sharing

One nifty feature that will go down well is that users can sync any document library to a folder on their PC, making offline access smoother – no client such as SharePoint Workspace is required. Additionally, SharePoint 2013 introduces the concept of ‘sharing’ – this is really the same permissions model we’re used to already, but with different semantics to hopefully makes things simpler for users. So I can ‘share’ a document library, rather than ‘grant someone contribute permissions’.

Apps for Office

An “app for Office” (known as an ‘Agave’ during pre-beta) is effectively a new form of “Office Add-in” – some good examples I’ve seen include a Bing map appearing next to some Excel rows containing addresses, or a Word Add-in which shows some SharePoint list items and allows them to be dropped into the document. Hopefully you get the idea. What’s interesting about it is that despite the client being Office, the development is done in web technologies such as JavaScript, CSS and HTML. It’s almost like an IFrame hosted in Office. This is kind of cool because there’s now a lot of potential for re-use across the browser and Office clients – i.e. I no longer need to learn Office APIs to target those clients.

AppFabric

AppFabric is a caching technology which exists as a standalone install (and has done for some time now – it doesn’t require Windows Server 2012). SharePoint installs it as a pre-requisite if it is not already present. AppFabric essentially joins together the memory of multiple web servers, and allows you to use this as a cache – in this way you don’t need to worry about different machines having different values in the cache, or having to use a CacheDependency or anything like that. Effectively you store name/value pairs and access them from anywhere. The cache can be divided into different areas (partitions), and there are options for making it highly available.

Summary

So, lots of new capabilities and lots of things  for developers to get to grips wit – and there’s lots I haven’t mentioned too. Like JavaScript templates (think jQuery templates for well-known SharePoint controls e.g. a list view) and use of Azure for workflow hosting. I’m sure good content on these can be found elsewhere (if not now, then soon).

Of course, this has been a technically-focused post and other folks will take a closer look at end-user enhancements. I’ll be covering a few technical areas in detail, as will many others, so it might be time to dust off the RSS reader and get on Twitter if you’re not there already :)

SharePoint MVP for another year

I’m privileged again to receive the MVP award for SharePoint. This is the 4th year for me and I definitely enjoy being part of the program. I’ve met a lot of great people, and I’ve had a lot of interesting conversations with product group folks - e.g. recently helping define how some upcoming IntelliTrace features for SharePoint development should work. Every year I like to jot down on my blog the community “things” I did in the previous year - this list is mainly for me rather than you, but here are some the things I got up to:

• Talks on Continuous Integration and customizing the SharePoint ribbon at the SharePoint conference in Anaheim
• Other talks in the UK (e.g. “jQuery and AJAX in SharePoint”) – at the UK user group and SharePoint Saturday UK
• Continuous Integration article series on the official MSDN SharePoint Developer blog
• 15 new articles on this site, including things like Extending the SharePoint 2010 social features and WebPartAdderExtension – a better way of deploying web parts
• Open source contributions such as:
• http://sharepointci.codeplex.com
• http://tfssimpleversioning.codeplex.com
• Interview with the SharePoint Podshow guys on performance and optimization

I also gave a couple of talks at Tech Ed U.S. recently, but I think technically they fall into the next “MVP year”.

As always though, I know I could do a far better job of serving the community, and blog comments are something I continue to struggle with. Seems the more articles are added to your “back catalogue”, the more comments will be generated. More recently I’ve started publishing them even if I haven’t got time to contribute an answer myself, but specific questions on what I’ve written will always get priority.

Anyway, it’s been a fun year – and with the next version of SharePoint round the corner, I think the next one will be even better :)