SharePoint 2013

Search Result Source: Why you should use them more often

SharePoint 2013 encompasses a very fancy query configurator and "builder" in the search results web part. An admin can configure the query to filter down and/or scope the results the search web part will show. This is fantastic news as you no longer need to write SQL to provide a simple solution for client requirements like:

  • "search results should only show images"
  • "search results should display results from HR department sub site"


Why a result source?

The biggest issue I have with this solution, is that it is almost entirely based on the on the "Local SharePoint results" result source. Which means that the search results web part will load the complete index and then apply the query rules.


I wonder however, why do we put such a load on the system to show the full index and then tell it that we'll only need 2% of the results or just the *.PSD files. We can speed things up by configuring a result source, so the system will only get the results from e.g. only the *.PSD files. This will result in a performance increase because both the result source and the applied query have faster loading times. This is much appreciated considering we're applying more and more front-end design to display templates. Whenever we can save load time, we should always do so.


Another benefit is that if we do want to add extra filters - for example when we have a result source for one site but two search result pages (no.1 = all and no.2 = documents only) - the result source can be applied to both pages. This results in an even better performance on the 2nd page, because the performance increase is applied twice. The loaded index is smaller and the filter is applied to a smaller result set.


Besides all this, there are also functional benefits related to using result sources. First of all, result sources can be applied to all result web parts within the collection of creation. So, when a more experienced admin creates a result source within a site collection, other less experienced admins within that same site collection can apply the result source to result web parts.


A result source will also help with version control and updates. When you configure each search results web part within the web part itself completely, the code is fragmented and can't be updated from a single source or be reused. This is not the case with result sources. These can be updated from the source and the source could be a Site, a Site Collection or a Web application/Tenant.


So to conclude, result sources improve performance of search results web parts, they are scalable and manageable.

When to use result sources?

In theory, a result source can be used for all search result web parts. It'll be a mess however if you create a result source for all detailed searches. A simple guideline is "when a scope is smaller than a site collection, more than three site collections (including my site/search center) are present or a filter is applied". What does that mean exactly? A few examples:


Result Source:

  • All results from site HR including sub sites.
  • All video files from site collection "Video".

Full index:

  • All results.
  • All results from a site collection (total no. of site collection is 3).


Next time

In the next post I'll share the details on how to configure a result source.

For now I would like to know if you use result source or why you disagree with using them.

SharePoint 2013 Apps: Back and Forth between Webs

I've been diving into Apps lately and was surprised on the User Experience and Interaction model in general. Don't get me wrong I think Apps are cool, but they ask for a very different mindset from a User Experience point of view.

App Web vs. Host Web

Apps are small specific functions or applications (like we know from our Smart Phones). In SharePoint one App has a very small and restricted environment (App Web) where all functions for that App are available. To make the App available, it needs to be added to a Site or SiteCollection (Host Web). This loose coupling has a lot of advantages when it comes down to security and upgradability etc. However integration in your SharePoint User Experience can be a real pain. To keep users in the right context while using Apps there are some possibilities.


Custom Actions

First and easiest solution to this is a Custom Action. Just like we're used to in SharePoint 2010 (and even 2007) it's possible to extend SharePoint functionality to the ECB (Edit Control Block) and the Ribbon using a Custom Action. A good place to start is MSDN:

But even though we provision new functions into the Host Web, the Action still takes us to the App Web. We have to provide good interaction models for the User not to get lost in the process (show the App in a dialog is one). And unfortunately we cannot use the Custom Action to add a script to the ScriptLink as we could have done with the Sandbox Model.

Summary: + Good to provide a Contextual link to your App (Possible to open in Dialog) + Easy to implement - Limited to ECB and Ribbon (Even Ribbon is limited. No custom Tabs can be added)

App Parts

An App Part is a WebPart that shows a Page from your App. Basically it's just an iframe that loads your App. The nice thing is that Users are kept into the context of the Host Web they're on. Still your code is running in you App and not on your Host Web. More on this:

Summary: + Integrates on a SharePoint Page in the Host Web as a WebPart + Possible to use WebPart Settings as Properties that will be passed to your App - When Upgrading your App, the App Parts need to be replaced and reconfigured.


User Experience has become way more important with this new release of SharePoint. The introduction of the App Model also introduces a new challenge on UX design. The two options I mentioned are steps in the right direction but still need good interaction design for Users to understand flow of the apps.

If you want to know more about Apps and UX challenges I can recommend this Blog Post:

SharePoint 2013: Display a User with Presence Indicator in a Custom WebPart

When building a custom WebPart that displays users, I wanted to show the Users as displayed in the people Search. screen1

Just a Picture with a small Presence indicator stroke on the left side. This is how Lync shows users as well. It's possible to use SharePoint JS functions to Render a User like this.

Getting User Data

To render a User the SharePoint 2013 way we need some Contextual Information about the User we want to display. For showing Presence we need the User’s SipAddress. Besides that I want to show the Profile Picture and the Preferred Name. With the new Search REST Api there are lots of easy ways to do this. In this example I'm using Search to retrieve some users based on a Profile Property. My REST Url is as follows:

"'Department=ICT'&sourceid='b09a7990-05ea-4af9-81ef-edfab16c4e31'&rowlimit='100'&selectproperties='FirstName, LastName, PictureURL, SipAddress, PreferredName, WorkEmail'"

I'm looking for people that have their Department property filled with "ICT". The sourceid is the GUID of the Default Result Source "Local People Results" (This is a fixed GUID same for On Prem and SharePoint Online). With selectproperties I can indicate what I want to get back from Search.

Handle Search Results from REST

The result object is a very complex object that needs some parsing. Even when using selectproperties, still some overhead is coming into the results. To get the correct Values based on the Fieldnames we can use the jQuery.grep() function to query the object array and get back the correct values. I use this function:

getValueByKey: function (key, results) { var postItem = jQuery.grep(results, function (e) { if (e.Key === key) return e; })[0].Value;

return postItem; }

The results argument is the Object Array that holds the results, the key argument is the Property Name of which we need the Value.

Next: Create a User Context

To render the User I use a SharePoint function "RenderUserFieldWorker(renderCtx, fieldSchemaData, userData, listSchema)". This function is available in the clienttemplates.js. First we have to Ensure that script file and then create the rendering. This script makes sure everything is in place.

EnsureScriptFunc("clienttemplates.js", "RenderUserFieldWorker", function () { ULS2Vv:; //Parse Results var results = data.d.query.PrimaryQueryResult.RelevantResults.Table.Rows.results; for (i = 0; i < results.length; i++) { //Get the correct properties var item = results[i]; var itemCell = item.Cells; var itemResults = itemCell.results; //Get Values for User var sip = getValueByKey("SipAddress", itemResults); var userPic = getValueByKey("PictureURL", itemResults); var fullname = getValueByKey("PreferredName", itemResults); var lastname = getValueByKey("LastName", itemResults); var email = getValueByKey("WorkEmail", itemResults); //Use SharePoint Render Template to render User with Presence var renderCtx = new ContextInfo(); renderCtx.Templates = {}; renderCtx.Templates["Fields"] = {}; var fieldSchemaData = { "PictureOnly": "1", "PictureSize": "Size_72px" }; var listSchema = { "EffectivePresenceEnabled": "1", "PresenceAlt": "User Presence" }; var userData = { "title": fullname, "email": email, "picture": userPic, "sip": sip }; var user = RenderUserFieldWorker(renderCtx, fieldSchemaData, userData, listSchema); } //Enable Presence ProcessImn(); )};

The variable user now contains the HTML to render a User’s profile picture with the Presence Stroke. The final step to activate the Presence is the function ProcessImn(). That function makes sure that all Presence Controls on the Page are showing the latest status.

The Presence only becomes available when you have Lync setup correctly. For Office 365 use the Desktop Setup to accomplish this.

Download a complete example right here!

SharePoint 2013 Hosted App Part III

In my Previous posts I created an App that retrieved data from a public website. SharePoint 2013 Hosted App SharePoint 2013 Hosted App Part II

I used that data and added it to my App List in SharePoint. In this post I will explain how we also can interact with our personal Timeline using the App Framework. If a song is added to the Playlist, an update is posted on the users Timeline.

App Permissions

All interactions between an App and the App-Host are restricted with certain permissions. These permissions can be set in the AppManifest.xml. A good reference to check which Permissions you’re going to need is MSDN:

To Read and Write from/to the Personal Timeline we need 2 specific permissions in 2 different scopes. Reading from the Timeline needs ‘Read’ permissions with Scope ‘User Profiles’. Writing however needs ‘Write’ permissions with Scope ‘Tenant’.

Schermafbeelding 2012-10-01 om 15.22.59


In order to interact with the Timeline using JavaScript, the library ‘SP.UserProfiles.js’ must be added to the page. The easiest way is to add the ScriptLink tag to the AdditionalPageHead Placeholder.

<SharePoint:ScriptLink ID="ScriptLink" name="SP.UserProfiles.js" runat="server" ondemand="false" localizable="false" loadafterui="true" />

Using the REST interface

Just to show that posting to the users Timeline was successful, the Timeline of the current user is displayed next to the Charts. A persons Timeline can be fetched using the REST interface.

var base = getParameterByName("SPAppWebUrl"); var url = base + "/_api/social.feed/my/TimelineFeed"; $.ajax({ url: url, cache: false, dataType: "json", type: "GET", crossDomain: false, success: function (data) { var TimeLine = data.d.SocialFeed; //do databinding }, error: function (request, status, error) { console.log("error: " + status); console.log("incoming Text: " + error); } });

Posting a Status Update

Posting on the Timeline using the JavaScript Client OM is similar to creating an Item in a SharePoint List. I used the following code:

// Initialize the current client context and the SocialFeedManager instance. clientContext = SP.ClientContext.get_current(); feedManager = new SP.Social.SocialFeedManager(clientContext);

// Create a link to include in the post. var linkDataItem = new SP.Social.SocialDataItem(); linkDataItem.set_itemType(; linkDataItem.set_text('sample'); linkDataItem.set_uri(track.Sample); var socialDataItems = [linkDataItem];

// Create the post content. var postCreationData = new SP.Social.SocialPostCreationData(); postCreationData.set_contentText("I added " + track.TrackName + " - " + track.ArtistName + " with a {0}."); postCreationData.set_contentItems(socialDataItems);

// Publish the post. Pass null for the "targetId" parameter because this is a root post. resultThread = feedManager.createPost(null, postCreationData);

The SocialDataItem is used to create a link within the Update. After this the only thing that is needed is to ExecuteQueryAsync().



In this case Marcel opened the App to add a track to the Playlist. Marcel also follows the administrator and therefor sees updates of administrator in his Timeline too.

This example can be downloaded here

SharePoint 2013 Hosted App

This will be my first post on SharePoint 2013. The buzz around the App Model is huge and so I dove in on a very basic level. Just to show how easy an App can be hosted in SharePoint and can consume Data or connect to popular websites. Like Facebook. No worries, no Authentication is being used. This Post it’s just to show how easy it is to create a SharePoint App and consume “free” data.

First things first

The very first thing we should do is follow the steps described by MS to setup your development machine for App Development.

Andrew Connell created a PS Script for this:

Create a new App

First start Visual Studio 2012 RC. Create a new Project and choose App for SharePoint 2013

Schermafbeelding 2012-08-21 om 17.08.34

Next give your App a name and fill in the Developer Site (created while setting up your app domain). I chose my default webapplication to be a Developer Site.

For this App we choose SharePoint-hosted.

Schermafbeelding 2012-08-21 om 17.09.46

Now we can see the App Template contains some modules for Scripts, Images, Pages and CSS files. Also notice the AppManifest.xml file which holds important info about your App.

Schermafbeelding 2012-08-21 om 17.19.38

Facebook Data

For this app I use the standard Facebook Graph API. We can use jQuery to get JSON data from the url we like. In this example I chose Microsofts Facebook page.

To simply bind the data on my Default.aspx page I use KnockOut JS. This is a very easy and fast way of binding data.


The project that you can download, results in an App that is displaying Page data from Facebook. It looks like this:

Schermafbeelding 2012-08-21 om 16.58.10

Schermafbeelding 2012-08-21 om 16.57.40