Searching...

Sitecore 7 came with the mission of expanding Sitecore's ability to cope with lots of content, i.e. lots of items.

The main challenge is Sitecore's reliance on a tree to store and present the content in the UI. A tree is not necessarily a good structure for dealing with large amounts of data.

One could identify three main features of Sitecore 7 that helped alleviate this reliance on the tree:

  • Search UI (and the openly available API it relies on)
  • Item Buckets
  • Search-enabled fields

Today I am going to write about the first of those points.

Search UI

A new tab was added, showing a magnifying glass, to give access to the new search functionality from any item in the content editor.

search tab

The search is constrained to descendant items only. The results are conveniently paged, and as they are querying a separate index, not the database, it scales nicely.

You can then click on a result to open that item and make any changes. The default behaviour is for it to open in a separate tab. I would not mind this too much if it were not because of the double toolbar syndrome.

double toolbar

In my opinion this makes the UI extremely confusing. I always recommend changing this behaviour by modifying the /sitecore/system/Settings/Buckets/Item Buckets Settings item.

bucket settings item

Select the option to open the results in a new content editor. Unless you are in the desktop, this opens the result in a pop up modal window. This is not ideal, but it is far better than the double toolbar.

modal window

It would be even nicer if the tree did not appear in the pop up.

better popup

Sadly it is not possible to configure it that way (without re-writing some code).
I have one other gripe with the way this works. I do not understand why doing a wildcard search gets me the actual item I am on as part of the results.

context appears in search

This one is easy to fix as there is a setting that changes that behaviour BucketConfiguration.ExcludeContextItemFromResult.

Another minor complaint is having a result for each version in each language . I would prefer to have one result, and then some information showing the number of versions, or languages. However this one is harder to fix, so my recommendation is to live with it. (Don't try to fix it with the BucketConfiguration.ForceClientLanguageInSearch setting, as it looks at the client language, not the content language).

Other functions

There are a extra functions available in the search UI by clicking on the arrow to the left of the text box

extra functions

In particular the recently modified and created items constitutes useful functionality. I just don't understand why they are hidden here, instead of appearing in the Navigate toolbar as standard buttons.

Filters

You can also apply filters. You can either access them from the list shown

filters

or type them in the textbox directly. The user experience is quite good. For example filtering with templates will use AJAX to show suggestions. Or selecting a date it will show a calendar.

calendar filter

Just beware that when you add multiple filters they are not ANDed but ORed . In many cases you are better off using facets instead.

Facets

This allows you to hide results that do not meet certain criteria. The available facets are shown on the right hand side.

facets

You can easily add custom fields to be faceted on. Simply add a new item to /sitecore/system/Settings/Buckets/Facets. You must specify which field from the index you want to use. Remember that by default, when Sitecore fields are added to the search index their name is used in lower case and spaces are replaced by underscores. So, for instance, if you want to facet on a Sitecore field called "Article Territory" you need to specify the field "article_territory".

facet item

There is also another small detail to take into account. If you want that facet to be computed for every single search, you must enable the Global Facet field.
You can alternatively only enable this facet when searching from certain locations. Then you must select it in a Standard Field called __Facets, under the Indexing section, in the item where you want it available.

Facets field

Search Operations

This feature is very useful, it is currently the only way of applying a command to multiple items at once using the Sitecore native UI.

search operations

The list of available operations can be changed by creating or modifying items under /sitecore/system/Settings/Buckets/Settings/Search Operations. Each operation maps to a standard Sitecore command.

Quick Actions

Whereas search operations apply a command to the whole set of results, quick actions allow you to apply it to an individual command directly from the search results.

There is a pipeline, of course, that populates the actions available. You can find it defined in the Sitecore.Buckets config under the name <buckets.dynamicQuickActions>. By default it shows a translate option, the available insert options and, in theory, available workflow commands.
You can also add actions to the list by using the Quick Actions field in the standard fields Item Buckets section. The selected actions will be shown for that particular item only (i.e. the setting does not cascade to children). I would envisage setting this on the Standard Values .

There is one issue though, in a standard Sitecore installation, those actions are never shown! It turns out the HTML code is there, but it also has a display:none attribute. I am no front-end coder, but a quick hack in the \sitecore\shell\Applications\Buckets\Styles\ListStyles.css file

.baketActionListWrap {
width: 16px;  
height: 16px;  
overflow: hidden;  
/*background-color: #fff;*/
background-image: url('~/icon/Office/16x16/gearwheel.png');  
background-repeat:no-repeat;  
position:absolute;  
bottom:15px;  
right:0;  
text-align:right;  
  padding:5px;
  /*display:none;*/
}

and I get something to show up.

quick actions

It would need some cosmetic work, but I think this could be an interesting feature. If nothing is going to be shown, I recommend removing the pipeline steps, so we don't waste valuable computing time calculating and rendering hidden unnecessary HTML.

Boosting

You can use boosting to alter the ranking of the results. In the UI, there is a standard field Boost where you can add a number that will be used to make that particular result more relevant. As outlined by John West in a blog post the boost will have a different effect depending on the type of item where you are setting it. All the boost values that are relevant for the current search are multiplied together and the final boost value, which is the ranking used to sort the search results, is obtained.

There is a small hiccup though, the default value for boost is 0. That means that you always get a 0, unless you have non-zero boost values for all the factors (highly unlikely). The solution is quite easy, just create a standard value and set the default boost value to be 1 (i.e. no boosting).

standard value for boosting

This way now I can change the boost and it will apply to my results. The general rule is to use numbers between 0 and 1 when you want to lower the ranking of a result, and higher than 1 to increase it.
As an example, set the boost value for the folder template standard values to a less than 1 number and it will show folders at the end of your results.
Just remember that some of the boosting is calculated at indexing time, so depending on what you change you might need to rebuild the search index to see the effect.

And if you want to try something even cooler, you can use rules to do the boosting for you!

Example of rule

Tagging

This is another hidden feature within the Search UI realm. It is just a simple taxonomy. The tags available are defined in the location defined in the Bucket Settings Item (by default /sitecore/system/Settings/Buckets/TagRepository) and they are stored in a standard field.

Tagging

In reality this is no different from any taxonomy system you could have created normally. In fact my advice is not to use this feature as it presents one main challenge: there is no easy UI for modifying tags, except for the Add Tags Search Operation which is broken, as it let's you select as tag any item from the tree. As the tag is in a standard field, regular authors are simply going to be incapable of using this.

Final thoughts

The search UI is a powerful tool. This is my check list to use it properly:

  • Make results open in a new window, not a tab
  • Remove context item from the results
  • Create any extra facets you may require
  • Fix the boosting by giving it a default value of 1
  • Use boosting to prioritise important results
  • Configure Search Operations if you want authors to apply commands in bulk

And of course remember that all of this depends on the configuration of your search indexes. That's a topic for another day and several posts!