EPiServer Find has gained quite a lot of adoption lately. A number of EPiServer’s partners and customers have realized the great value Find can add to any EPiServer project.

For instance, fellow EMVP Ted Nyberg wrote this on Twitter a while ago:

Sometimes though, I meet partner developers who haven’t had the chance to try out Find yet. For those it’s not really clear what Find is, or rather why it’s something quite different compared to the “traditional” search solutions that we are used to working with.

Find by example

So far this year I’ve worked on three different EPiServer 7 sites. On all of them EPiServer Find is an important component. What’s interesting is that while some of them use Find for free text search, free text search functionality hasn’t been the primary reason for using Find for any of them.

Case one – newsroom

The first site is a classic corporate web site. An important part of the site is its newsroom in which content from a number of external sources is aggregated. Within the newsroom the imported content should be easily sortable, filterable and searchable.

The newsroom content is also used on other parts of the site. Different newsroom content should be listed and used depending on the context.

While some of this functionality could be achieved without Find, using Find made it really simple, and fun, to build. To some extent we could have achieved the same result using FindPagesWithCriteria, but that would have brought performance problems and taken longer to build. We would also have had to cut some functionality that FPWC simply couldn’t have handled.

Case two – freeing the taxonomy from the page tree hierarchy

The second site is a new version of this, my own, site. There I use Find to enable a different and more loosely coupled content structure than the native tree structure that EPiServer CMS offers.

On a classic EPiServer site content is organized in a hierarchical structure, the page tree. This structure is almost always used in navigations, breadcrumbs and site maps.

In this case however organizing content in a tree structure isn’t optimal. Content should be divided into categories rather than tree nodes and content should be easily cross-published among various places on the site.

The CMS’ API is optimized for finding content based on the page tree making such site structures hard to achieve. Especially if there’s a lot of content and performance is important.

By using Find I can easily decouple content from the page tree without worrying about performance implications and can instead focus on building a good taxonomy on the site.

Case three – enabling editorial work flows

The last case is a media site with a huge amount of content. Here too content need to be decoupled from the page tree which, due to the content volume, would have been impossible without Find or something similar.

In this case Find also plays another vital role – enabling editors to work. The page tree and block folders, which are at the core of EPiServer CMS’ edit mode, doesn’t fit the needs of editors on news/media sites.

Instead of working in the site’s structure, editors work with content that is, or is about to be, published during the day – during the current news cycle. Luckily the CMS’ edit mode is highly extensible making it possible to add such functionality to EPiServer.

There’s just one problem. Those UI components need to get their data from the server. Fast. The CMS’ API which is optimized for content organized in the page tree isn’t very good for such non-hierarchical listings.

Find on the other hand is great at finding and sorting content no matter where it’s located on the site, making it the perfect backend for such components.

Beyond the search page

Most traditional search engine vendors talk a lot about “the search page”. That’s natural as their products are very much geared towards free text search functionality.

Although their search engine index’s certainly could be used for other things, the way content is indexed using a crawler and the way their client APIs is designed that would impose time delays. Not to mention tedious work for developers.

One unfortunate consequence of the extreme focus on “the search page” is that the word “search” has been more or less synonymous with free text search in the minds of us developers, not to mention our customers.

Find can certainly be, and is by a growing number, used for free text search with great results. However, as illustrated by the three cases above, search is so much more. And here, in “content retrieval” or querying, is where Find’s true strength lies.

With EPiServer Find in an EPiServer project we not only have an easy way to build free text search but a whole new way of querying for content.

Find essentially duplicates the content objects stored in the CMS’s SQL Server database into a document database. By doing so Finds adds another dimension to developing websites. This new set of tools perfectly compliments the hierarchical view of the content that the CMS’ API is great at.

Conclusion

A search engine shouldn’t just be able to handle free text search.

It should, by utilizing the power of an inverted index, enable us to find and display content in a wide range of scenarios. It should free us as developers from tedious tasks and performance problems.

It should allow us to focus on building great things for our customers and users.

That’s what Find was built for. That’s why I use Find in all of my projects.

PS. For updates about new posts, sites I find useful and the occasional rant you can follow me on Twitter. You are also most welcome to subscribe to the RSS-feed.