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):
- 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 :)
