First version of Delve is available

The first version of Delve formerly known as “Project Olso & Office Graph” is now available.

So what exactly is Delve? Here is what Microsoft says:

Delve (Codename Oslo) & Office Graph

Delve (Codename Oslo) is the first experience to use the power of the Office Graph. Delve is a new way to search and discover content across Office 365 based on personalized insights. Delve will be available as a Windows 8 app, on mobile devices, and integrated in the Office 365 web experience. Office Graph is an underlying technology and a suite-wide intelligence fabric that will help you discover content and make new connections. The Office Graph analyzes signals and applies machine learning. Personalized insights are built up for each user, based on their behavior, their relationships to content, topics and one another. Content and signals are captured from Exchange Online, SharePoint Online, and Yammer.

Source: http://office.microsoft.com/en-us/products/office-365-roadmap-FX104343353.aspx

The Delve feature is located in the Office Bar at the top of the O365 site. Delve is only available for O365.

Here are some additional useful links:

·         https://support.office.com/Article/Office-Delve-for-Office-365-admins-54f87a42-15a4-44b4-9df0-d36287d9531b?ui=en-US&rs=en-US&ad=US

·         http://blogs.office.com/2014/03/11/introducing-codename-oslo-and-the-office-graph/

·         http://blogs.office.com/2014/09/08/milestone-office-delve/

Delve shows content from SharePoint team sites and OneDrive for business content. In the future, we will see more content sources to push content to the Office Graph, such as email attachments, meetings, group content, video portal content, Yammer signals/shares etc. We will also see an API for Delve in the future. The API will probably be a REST-based API supporting CRUD operations.

Delve looks like this:

Going to Query Editor in a search result webpart we can see a new Result Source:

This result source is not shown under SharePoint online administration or in the site settings menu. It’s only visible in the Query Builder. The Office Graph gets its own index. We can assume that this new result source is mapped to the new Graph Index. The new result source is not showing any results using it in a search result web part.

Is Delve only another content aggregation?

In SharePoint / SharePoint Online, we have several sites and web parts showing content based on search and social indicators:

·         My Documents

·         Recent Documents

·         Docs I'm following

·         Suggested documents to follow

·         Documents Shared with Me

·         Documents we have in common

Aggregating all this in one page shows that the content is mostly related:

So is Delve only an aggregated view of all this? No it is not! Delve is based on the Office Graph, which is a kind of machine learning to map the relationships between people, content, and activity that occurs across Office 365.

To give you an idea how this works, let’s have a look at the following example.

As part of Google, we have an Analytics engine called Google Trends. http://www.google.com/trends/

I use this engine to get the following report.

• Search term 1: Hangover
• Search term 2: Vodka
• Entity: Time

That means: Item1=Hangover Item2=Vodka

Item to Item recommendation shows a correlation between this to search terms / items at the end of December every year – at New Year's Eve ;-)

There is a correlation between these search terms and the date New Year’s Eve. In Delve it would be two people who are working both on the same document and because of this correlation, the system (Delve) is showing that document in the context of “trends around me.” The backend logig, algorithems and ranking models of Delve respect those correlations based on so called “signals” A signal for example is generated whene a user clicks on a document etc.  SharePoint Analytics works in a similar way. In SharePoint Analytics we talk about “events” which is the same like a “signal” in Delve / Office Graph. Both techniques are collecting, aggregation and analyzing what user are doing and is generating correlations  between content and content and users. Both solution Delve / Office Graph and SharePoint Analytics doing similar analytics but Delve is going a step forward and will soon also integrate Yammer and other components from O365.
To complete this, let’s have a look at how the SharePoint features like Items “Related to Current User” or “Suggested documents to follow” works.
“Items related to current user” is based on a result source. This result source can be used in a content search web part:

“Suggested documents to follow” is based on the managed property “recomendetfor”

Roundup

So the following features are based on SharePoint Search and SharePoint Analytics. They are part of SharePoint on-prem and can be used without Office Graph and Delve.

• My Documents
• Recent Documents
• Docs I'm following
• Documents Shared with Me
• Documents we have in common
• Suggested documents to follow (with social impact)
• Items related to current user (based on a system result source)

Delve is based on search driven solution and the Office Graph, but this is not SharePoint Search or SharePoint Analytics. Delve has its own index and its own backend system as part of Office 365. Delve is not available as part of SharePoint search-driven solutions or WebParts. Also the Office Graph can not used as a result source in SharePoint Search Querys or Search WebParts. It’s a separate and independent solution.

• Delve

When you add Delve on top of the traditional search results, this all can be a little bit confusing for end users and decision makers; a company needs a strategy for all of this. I think that Delve is the future of all these ideas and techniques. Delve will get an addition push with the upcoming Phone and Windows Apps, which allows us to get access to all this using mobile devices and without using the web interface of Office 365.

Again, you need more description here. How is this related to the bullet list above?

Belonging to comment NB5: Delve is new and not based on SharePoint Search or SharePoint Analytics feature. Delve had its own index and its own backend system the Office Graph. All this is not available in std. Search Driven Solutions build with  regular SharePoint Features like in the “Search Based” bullet list.

Project Oslo and the Office Graph – first indications

At this year SPC in Las Vegas, Microsoft introduced codename Oslo and the Office Graph. If you want to see how the product should look watch this YouTube video:

Microsoft is working on the product. The TAB program is about to start and Oslo is now appearing with status "started" on Yammer release Schedule: https://about.yammer.com/success/engage/grow-your-network/release-schedule/

In my Office 365 Tenant belonging to my MSDN Subscription I also found the first indications. I have a look in several other Tenants and can actually not found anything of this. Not sure it´s because of this Tenant is part of an MSDN Subscription.

New result source

Interesting artefact is the new result source: “Local SharePoint Graph”

This result source is not shown under SharePoint online administration or in the site settings menu. It’s actually only visible in the Query Builder. Latest news from Microsoft says that the Office Graph gets its own index. We can assume that this new result source is mapped to the new Graph Index. Actually the new result source shows the same results like the “Local SharePoint Results” source.

Stay tuned about upcoming news about Project Oslo & the Office Graph….

Building Search Driven Solution with SharePoint 2013 Part II

Part I is about Search Driven in on-premise environments

Part II will show the options and differences with O365 SharePoint Online

In Part I I wrote about the options and scenarios with Search and Search Driven Apps in SharePoint 2013 on-premise. Now let’s see which option we have using the online version of new SharePoint 2013.

There are two big differences in SharePoint Online:

1.       We did not have the new Webpart Family “Search Driven Content”.

So in fact we only can use the common Search Result Webpart and its options within the Query Builder to create dynamic search solutions

2.       In SharePoint Online we are not able to configure own content sources ore manipulate the settings like Crawler scheduling etc.

Missing "content source" option in SharePoint Online and its impact

Because of the option “content sources” is not available in SharePoint Online we have to look for alternatives to bring in own content in our SharePoint Online environment. Another point is the index freshness which cannot be manipulated setting up Crawler scheduling ore manually decide to configure continuous crawling option.

Index freshness

Also in the official technet documentation is not a clear statement continuous crawling is set up by default for SharePoint Online or not. My own experience say: “Yes, it is”. I get search result in the index within 2min – 4min. This is really fast and for me in the most scenarios ok.

Own content

To bring in own content in you SharePoint Online Search you have to use “Result Sources” To set up those 3th Party Result Sources you can use “Site Setting” to configure them in the context of a Site Collection ore SharePoint Admin Center to do it global.

The dialog for setting up a Result Source shows the option for bring in own content:

·         Local SharePoint

·         Remote SharePoint

·         OpenSearch 1.0/1.1

·         Exchange

 

For all options you have to configure a security context to access the result source. Using Remote SharePoint you can use SSO or path thru authentication. Using Open Search we have the option to use Anonymous, Basic Authentication, Digest Authentication, NTLM, Form Authentication or Cookie Authentication. Using Remote SharePoint to call an on-premise SharePoint Search you have to set up a Search Federation based on an Identity Federation.

In all cases we had to configure a Remote Address and we can configure a Query Transformation (as described in Part I) to filter ore manipulate the query which is send to the remote system.

In my demo tenant I simply use some open search based systems.

 

Source	Source Url
Twitter	http://search.twitter.com/search.atom?q={searchTerms}
Facebook	http://search.live.com/results.aspx?q={searchTerms}+site%3afacebook.com&format=rss
YouTube	https://gdata.youtube.com/feeds/api/videos?q={searchterms}

(These can of cause also be remote endpoints for your LOB systems or other on-premise sources)

Setting up those systems as a “Result Source” get me the option to use them in my SharePoint Online system to build Search Driven experiences.

Search Driven experiences and solutions in SharePoint Online

Easiest way to use the new result source and within them remote content is using them in the result Webpart. In this example you can see an overview site in my SharePoint Online that aggregate News from configured social media sources based on Result Webparts:

For example filling the atwork area for Twitter news I configured the Result Webpart with those setting:

·         Setting up the “Select a query” with the “Twitter” Result Source

·         Fill in a query that focus to the desired results

Using the configured result sources within Query Rules (as described in Part I) we can build focused search experience like this social media search page:

Search Driven Solution can of cause also build based on SharePoint Online content. Here you see an example based on content placed in SharePoint Online lists ad libraries:

And of course you can mix results coming from remote sources and results coming from your SharePoint Online source.

This Webcast shows the described samples in action:

Building Search Driven Solution with SharePoint 2013 Part I

Part I is about Search Driven in on-premise environments

Part II will show the options and differences with O365 SharePoint Online

Search Driven Solutions are not new in SharePoint 2013. But with SP2013 they reached a new dimension and there are much more out-of-the-box Webparts and options to work with content that is in your search index.

Admin Stuff

Why to use Search Driven? Good question. Let’s ask “why not”? The answer is the index latency. Search Driven Solutions are based on the search index and that means that the data freshness depends on the index freshness. With new feature Continuous Crawling and other solutions like Event Driven Crawling we can realize a really up to date index. Depending on you environment you can realize an index freshness in the scope of 2 minutes or so. Some other points in the context of Search Driven Solutions are:

·         Separate presentation from storage

·         Flexible and dynamic

·         Breaking down site collection boundaries

·         Eliminate large list thresholds

·         Allows flexible & dynamic publishing

 

Special Data means Special Search and special Search Results

Not in every case we have to choose between normal SharePoint Search and Search Result Webpart ore using Search Driven Solutions. There is a very useful and powerful option between. With SharePoint 2013 there are some new features. In the context of “Special Date means Special Search and special Search Results” we will now have a closer look on “Result Source” and “Query Rules”.

Result Source

Working with search based solutions mostly we start with a “Result Source”. Result Sources are places under Site Settings or if you would configure them for the complete farm in the search service application. A Result Source had some basic parameters:

Protocol: defines from where the results are coming

Type: focused between content and people search

Query Transformation: gives us the option to focus which data is shown in this Result Source using Search Syntax. Also we had the option using the Query Builder to define the Query Transformation.

To use a Result Source we had to configure search result Webpart to use this source. This is simply configured in the settings of the result Webpart:

Query Rules

Query Rules are used to manipulate search query. A Query Rule always based on a Result Source. That’s why we have to start with a Result Source. Query Rules are also based in the site setting ore in search service application. Working with Query Rules we had two main parameters.

1.       Query Condition: this parameter defines under which condition the Query Rules take effect.

To do this we had several options. The easiest way is “Query matches Keyword exactly”. But we also can use Termstore using the option “Query matches Dictionary exactly” This brings many powerful options. For example if you extend you Termset which is referred you not need to reconfigure you Query Condition. Also in Multilanguage environment this can be useful.

2.       Actions: The section configures what should happen if a Query matches.

We can configure a promoted result which is similar to Best Bets we know from SharePoint 2010 are we can place a Result Block.

Result Blocks are a new feature that allows us placing a separate block containing the data we configured based on our Result Source in top of the search result Webpart. Every Result Block can be configured using Query Builder. For example if you will use a special Result Block only showing pictures the configuration should be like this one:

·         Query: {subjectTerms} contenttype:image

·         Settings: Item Display Template -> Picture Item

Display Templates are also a new feature in SharePoint 2013. They allow us to use different visualizations based on content type or so. Details see here: LINK

As shown in this screenshot:

Bring all this together we can deliver special search for special data.

To get a result like this we had to configure a Result Source, based on this Query Rules and then use the Result Source in a search result Webpart. Detail Step by Step walkthrough is shown in the Webcast at the end of the post.

Search Driven Publishing Model

The above solutions are all based on a search query which had to be filled in a search box by a user or had to be configured as a “fixed keyword query” in the settings of the search result Webpart. Now let’s see how we can create dynamic pages showing content based on Search Querys using the new Webpart Family “Search Driven Content”.

As you can see there are preconfigured Webparts for different scopes. The context driven Webparts like “Popular Items” and “Recommended Items” are based on search analytics, user context and user activity. Other ones like “Pictures” or “Pages” containing a special visualization based on the contented type. The “Search Driven Content” Webparts can also be used to visualize search results based on a search query which is typed into a search box. All search Webparts can combined which each user. This is used configuring the following example:

Here you can see the “Search Driven Content” Webpart for Pictures. In the settings dialog the Display Template is configured to show “Picture on top, 3 lines on bottom”. Under Property Mappings you can choose which Managed Property are used to fill the lines. In the context of the shown Refiner Webpart “Refinement Target” is configured to the “Search Driven Content” Webpart Pictures. The binding is based on the Title of the Webpart.

 

Solutions based on the Search API

The Search API allows use building Apps ore other solutions based on the content coming from the search index. For more information about the SharePoint 2013 Search API look here: LINK

Here is a example based on my demo environment:

http://win-ful28kv4389/_api/search/query?querytext='contenttype%3Aorbeabike'

Using this query the result looks like this:

Using this XML we build a demo App showing the same data like in the above shown search result Webpart using the Result Blocks:

 

Webcast with hands on system demos:

 

What’s new within SharePoint 2013 Search? – PART III

PART III: A look in the deep what’s behind the new Search functions like “Search Dictionaries”, “Query Builder”, “Query Client Type” etc.
(Concern that this is BETA stuff. Features and functions can be changed or shift until the final release!)

New / Updates Ranking Model functions:

Custom ranking models are managed through PowerShell using XML files as it was in SharePoint 2010. Ranking Model for a specific query can be selected at query time by setting the RankingModelId of the query; otherwise default is used.

The PowerShell cmdlet is: New-SPEnterpriseSearchRankingModel

For more details about the underlying XML schema have a look here: LINK

So this example shows all Ranking Models in my demo system. And you can see which default is:

You can use the configured Ranking Models for example in the Query Builder (details see below in the Query Builder Section):

Query Spelling Correction:

This function is hosted in the Termstore. We can now easy configure “Exclusion” and “Inclusion” Terms. Another big benefit is, that Terms configured in the “Inclusion” Termset also used for “Did you mean” functionality.

So this example showing in the Pic would result in searching for ”EI” and didn’t get any results the system will suggest “Did you mean ExpertsInside”

Query Rules:

Query Rules are new in SharePoint 2013. It is a feature that gives us the option to tailor results in a very flexible way. Query Rules are set on Site Collection Level.

A Query Rule has 3 main parts:

-          Query Conditions

o   The conditions defined when and in which context the rule became active:

-          Query Action

o   In this section we can defined what happened if the rules matched. This is just a little bit similar to what we know as “Best Bets” or “Visual Best Bets” from SharePoint 2010, but much more powerful.

-          Publishing Options

o   These settings control when the rule can fire

Query Client Types:

Query Client Types are also new in SharePoint 2013 Search. At this time poorly not really more details are available on this new function. The idea behind is using the client the query is send from to do specific throttling etc: “Applications are prioritized by tiers. Top tier has the highest priority. When resource limit is reached, query throttling becomes ON, and search system will process the queries from top tier to bottom tier.”

Query Builder:

Query Builder is a tool in SharePoint 2013 Search which we can find in different places. For example the Query Builder is available in the “Result Sources” section (Result Sources are in the next Part IV – Admin Stuff) and also in the “Query Rule” section etc. Query Builder is available when we have the option to manipulate search query ore refine it. The Query Builder has 3 tabs:

-          Basic:

o   The Query is built here. You can use Keyword Query Language to add keyword filters and property filters. Keyword filters query the full-text search index.

This call for example will only show content where the “Author” is the logged on user.

-          Sorting:

o   Here we can manage how the results are sorted. We can use a Ranking Model ore use a Managed Property for that job

-          Test:

o   Test tab in the Query Builder is to evaluate the query that you built. You can experiment there to see whether changing variables would have the effect that you want on the query.

Stay tuned for the next parts in this series:

Part IV: Admin Stuff

Part V: Frontend Stuff