SharePoint Online Search: Add a Refiner for Content Type

2015-12-21_14-00-52This is yet another in the “Things that Make You Go Hmm…” category. If I only had a nickel…

I would think that one of the most common needs on a search results page would be to add a refiner by Content Type. After all, we all have robust, sensical information architectures in place to improve performance in our organizations, right?

When we create a new search results page in a Search Center, we get a few refiners out of the box that look oh-so-promising.

First there’s ContentTypeId. We all know that Microsoft uses big, ugly ids and GUIDs under the covers all the time. Sometimes they translate easily into whatever they represent. This isn’t one of those times.


Well, what about contentclass? That looks sort of almost useful. But it isn’t. Values like STS_ListItem_DocumentLibrary won’t really help anyone.


Oh, I know. Let’s add the ContentType Managed Property. That’s what works almost everywhere else. Well, except here, as the values don’t make sense to humans, as they are things like application/pdf Document or application/vnd.openxmlformats-officedocument.presentationml.pres… Yes, the ellipses are appropriate here. Who know what that means?


Finally, I found a blog post from Henri Merkesdal that retrieved my sanity. There’s a property way down the list called SPContentType that does exactly what we want.

Ahhh. That’s much better. Thanks, Henri!


People Want Different Things

Dan Antion (@dantion) did a great post over on his SharePoint Stories blog this morning called People Want Different Things. Dan does one excellent post per week on that blog. They arrive every Saturday morning, and reading it is usually one of the first things I do of a Saturday.

Today’s was a great post, as always, and prompted me to write a comment, much of which turned into this post. Dan’s post hits on something I feel very strongly about: there is no one-size-fits-all concept with SharePoint.

There are many, many people out on SharePointLand who seem to think that there is one way to do any one thing in SharePoint. Usually it’s the way that they know best, and is sometimes the way that they are selling (though sales people in SharePointLand seem to be far more ethical than in the other lands I have visited).

This mindset can apply across many dimensions: development, branding, information architecture, process implementation, you name it. There’s a reason people joke about what I and many other SharePointilists usually say, but the right answer is almost always “It depends.”

In Dan’s post, he gives the three main ways he approaches most of his SharePoint work (I won’t repeat them here, read Dan’s post), and I happen to know that there are favors and variations on the three (the jazz masters have nothing on us SharePointilists) and there are probably a fourth and fifth or more some days, too.

And that’s Dan’s point, I believe. Using SharePoint has some science to it, but to a large degree it’s more art than science. Anyone who marches into a new client, project, or meeting thinking they positively have the answer up front is more than likely wrong. SharePoint is a collaboration platform first and foremost – which can make it frustrating to use in other ways – and building stuff in SharePoint ought to be a collaborative process. I call that collaborative development, and whether you label it with other buzzwords like Agile or not, I firmly believe it’s the best approach.

So it’s not just that People Want Different Things; it goes beyond what any one person likes. It’s what the right answer turns out to be. Sometimes you don’t truly know that answer until you have finished. Of course, work on SharePoint-based solutions should never really be finished, but that’s another another post for a different day.