For that to work, apart from the overall big blocks to be in place and working seamlessly (which is the absolute minimum required) – you need to be VERY attentive to details.

What happens when user enters a place in the system where they are not usually required to work, are they properly guided? What do they see if they click on a little link somewhere in the corner? Does every image has an Alt text attached to it? Do your buttons have tooltips? Do the users have alternate views on all content? Do the system communicates abnormal states in a descriptive way and guides the user towards the solution? Is the UI logically laid out? Did you REALLY think what property should go on which tab? Have you setup the property names in a way that they make sense to non programmer? Do they have descriptions?

Part of the job we do is help sometimes troubled EPiServer customers get their solution built elsewhere or in-house to work, and I seem to be noticing some patterns which we have addressed in Cognifide as being bad practices. Many of those stem from the lack of research of the content served being done in the discovery phase.

Discovery phase? What’s that?

It seems that a great deal of projects does not seem to be well thought out in many aspects. When you look at the solution, It feels like a developer just got some templates and ran with them. Once the front end matches what the html templates outline, the solution is pushed to production and forgotten by the design/development agency and the poor customer is struggling with it for years trying to improve the ever degrading performance and fighting the CMS UI that’s been thrown together in a rush. Possibly aggravating in the process and rebuilding it again and again.

You need to realize that once your site goes to production, the trouble begins for your customer, not ends.

Understand your content, please

A very basic tendency for a lot of them is storing all the content of one type under a single tree node. or a very basic hierarchy. But:

• What is the volume of content in the start?
• Have you talked to the client about the maintenance of the content?
• How do they plan to store older content?
  • Are they archiving it?
  • Do they plan to serve it to general while archived?
  • Is the old content actively browsed on the CMS side?
• What is the volume increase over time?
• What is the profile of the content? Is it a catalogue? Chronological news library?
• Is there a taxonomy in place?
• How often and which content is being modified?

EPiServer shows pages in a tree, and while we have observed the CMS performance improving over time there are some basic scenarios that the hierarchy structure will never be able to deal with efficiently if not well thought out.

So your potential edge case scenarios might be that the customer has:

1. 10 000 articles that need to be migrated for the site to go live, but they only plan to add 2-3 a month,
2. They might be starting fresh but they plan to add 20 to 30 articles a day!

How do you deal with those?

Obviously the worst thing you can do is to put them all under the “Articles” node. The customer will be frustrated to no end! Both you and the CMS reputation gets damaged while they try to do any basic thing in the CMS.

In the first case you need to work with the client to dissolve them into the hierarchy that’s granular enough to leave you with the 20-50 articles per node tops. Dividing it into 10 categories of roughly 1000 items won’t do! If the page names are meaningful, you may attempt to create a structure based on the first and second letter of the articles. This works best for directories of people or places.

The second case is probably going to happen to you when you will be working with any kind of news site, be that intranet of sorts or a news agency, TV portal or an information broker. In which case, it seems to be making the most sense to put the content into a chronological structure. Have a node for each year, month (and day if needed) there is an article.

AUTOMATE!

When a user writes an article that is supposed to fit into your content plan, move it into the proper node automatically. In the first case, move it to the proper category or based on the page title move it around to the proper place in the catalogue. In the chronological plan, move it to the day or month node upon creation. If a new node needs to be created for it – that’s your responsibility to do it. Organize the content for the user or you will be in a world of pain sooner than you expect!

Those tasks are easily automated by hooking into the page save and create events. Your customer will love you for it.

Naturally you don’t necessarily have to have a single plan on a given site. A site can have both branches with news-like plan and directory-like sub trees.

The base line is – you need to plan it ahead, and you need to learn about the content profile.

Distinction with a difference

You need to realize the distinction between the content and the presentation of it. Don’t try to cram the content into the browsing structure. Separation of concerns should not be limited to code organization. Separate concerns in the content structure as well.

Have the user trip designed around the best SEO practices. The hub pages should make sense from the visitor’s perspective. DON’T try to put your articles under it just because the hub page browses them. this may work for a little tiny sites but then again, those are not the sites that you will run into troubles because it basically means your customer is barely ever touching them.

Have your content stored in a separate branch and reach out for it with a tag set that is related to the hub page.

Build a logical taxonomy and stick to it!

That basically means – treat your content equally no matter where it’s stored – preferably having it tagged with a high performance framework like the Faceted Navigation Framework published by Cognifide some time ago or make it Lucene.Net based. You can try to use the EPiServer built in categories. We have had limited success with it and the performance of FindPagesWithCriteria (which we have effectively banned from our arsenal) but I was told the performance in that front have improved greatly in the latest EPiServer CMS release.

Regardless – don’t rely on the page hierarchy structure to select the content, it doesn’t matter where it is, the metadata is what should be driving the content stream. You can hand pick your navigation links, fine, but article lists, news, announcements, events, treat it as a single content stream. Use a taxonomy to divide it into categories and you will be much happier in the long run as you will gain much more flexibility to reorganize the structure and move the content around when its profile changes later.

Using the EPiServer CMS for nearly 4 years now, those are the basic principles we have come to establish.

I wonder what are your practices? Where do you think our practices do or do not fit your design philosophy? Is there anything we could do better? Do you have practices regarding content planning? How do you analyze the content to make the best plan for it?

So how is the faceted engine structured?

Content provider

As you can see the driving force behind the engine is the Facet Tagged Content Provider. If you know EPiServer, the basic functionality of the module is roughly an an equivalent of find page with criteria for categories, which allows for searching pages tagged with facets with exclusion of some other facets and tagged some optional data, the module however is paging and and allows you to plug a feedback event handler so that your controls can accept or deny a story before they are sent to is and take part in the paging. The stories are provided to you in reverse order of publishing so you always get the latest stories first, (pretty much what any blog and any news site wants).

Another function of the content provider is assertion of story uniqueness on the page. This is actually a pretty cool mechanism that deserves closer attention.

Let’s imagine a page having a control with “main story” that is pre-selected by an editor, and then some “featured stories” also pre-selected, then there is a control with “latest news concerning facet A” and a “latest news concerning facet B”. The problem with this scenario is that if a story was pre-selected for the “main story” and perhaps then someone added it to “featured stories”, and the story actually is tagged by facet A and facet B – in a traditional search you would normally get it in all of the controls… not cool!

The solution that we’ve come up with is based on a free market rules. And the procedure is as follows:

1. The request starts and the engine opens a bidding for articles.
2. All the controls request their interest in stories by either providing the engine with pre-selected stories they would like to display or asking it to provide the freshest content based on the facets the content is tagged with. They also provide it with their value (priority). And a callback for the engine to provide them with the stories.
3. The acceptance phase ends and the engine distributes the stories looking from the highest value controls down the list in the following way
   • when the control provide the list of articles if so check for each article if it has not been taken yet, and otherwise feed it back to the control
   • otherwise if the control provided it with the facets it’s “interested in” it asks the tagged content store for articles tagged with this context and feeds them to the control if they have not been otherwise provided to another control with higher priority, until it reaches the number requested by the control. (this way of providing articles also allows for paging).
4. Upon satisfying all the controls the bidding is closed and all articles become available again.

Content Accelerator

Content accelerator is a caching module that we have made mandatory that all of our EPiServer calls must pass through. The engine turns the pages into objects with a well defined and hard typed objects rather than a-bag-of-strings-and-the-likes your usual PageData is.

This makes it much more efficient for us to cache only the important data contained in any given page and only the data that we use frequently, e.g. page name and page URL that are used by URL provider and that are likely to be called multiple times within any given user request. This has been been implemented to compensate for the slowness of GetPage calls.

For that to work effectively we always tread content accelerator as a proxy for GetPage – which allows us to filter any expired or not yet published pages faster and refresh the content and accessibility for everyone, any time any given content is refreshed.

The For this concept to work – any page type that is going to be used in it has to have its own class added to it with the properties you will usually access (this however should be done with caution, for example you can cache article intro, but caching a potentially big article is a bad idea – also a full article text is very unlikely to be displayed on a high traffic page so caching all of your article full texts will not offset for a potential quick running out of memory).

Also the content cache is written using generics in a way that allows you to specify a multiple classes for any page types – the class consuming the cache defines how it wants to treat the content and access it. The different cache classes will then be chain linked and refreshed.

The content expires on an arbitrary set time (1 minute in our case but you can specify any other period), but we’ve also written a web service allowing for expiring a page-cache-item whenever it is changed on any of servers in a multiserver scenario. This for this to work – you have to plug into the global EPiServer event handlers. Which I’ll describe later.

The accelerator is used extensively by the faceted engine, but it can also be used directly and is completely independent of the rest of the faceted engine.

Facet Context Provider

This provides the control with ewasy facility to retrieve the facets with which the request was performed.

Facet URL Provider

This service allows you to construct URLs based on a facet context – with automatic determination of a preferred visualisation (hub page). Naturally you can still force the provider to format the URL for a pre-determined page. The effect will be a request that can later be succesfully parsed by the Context Provider once that URL is executed on the server.

Auto Tagging Module

This block which originally was a separate module is now basically shrunk to a single method that you can plug into EPiServer in the Global.asax. The routine tags a page with facets predefined in its parent, during the process of a page creation. This is useful for tagging e.g. all the “technology” stories with “technology” facet and an “News” facet once its created in the “Technology articles” branch.

Furniture

Part of the faceted navigation, but not directly part of the engine are editors for facet roles, the very facets and facet selectors.

First of all we have to explain the nomenclature as it is going to be used quite a bit. A few terms we use pretty extensively are:

• Facet – this is roughly an elaborate version of an EPiServer (or Wordpress) category. One of the problem with EPiServer category is that it is just that and absolutely nothing more. There is no way for attaching metadata and conditional structuring of the category tree. There is no way to assign them roles. Facets provide you with much, MUCH more.

This article is a first of a series describing the faceted navigation system for EPiServer that we have internally developed in Cognifide and that’s already proven to be a robust solution for delivering tagged content a heavy traffic site, which will be released shortly as an open source project. The article outlines some pitfalls of EPiServer that we’ve run into and the nature of the project in which the module was used first and which influenced a lot of our design decisions.

This article and the Faceted Navigtation module is developed on EPiServer 4.61 and not the latest version 5 of the CMS so far, so mind that some of my reservations may not be a problem if you’re just starting to work on a brand new project and have the luxury of using new features of it.

Also (which may be a good thing) our sites uses a different approach to navigation the content, we do not really care much for the tree structure, but we treat all EPiServer pages equally when looking for content because of how the site is designed from the creative point of view.

The project is a vast site with:

• tens of editors working on it simultaneously.
• millions of uniques per month
• tens of thousands of articles in just about half a year
• 5 IIS servers working in tandem on a single SQL database
• The page cannot be cached as a whole as it contains dynamic and Geo-targeted content.
• The content on the page changes every other minute or more often
• There is a great deal of automated content coming from various feeds.
• A content can be both feeded automatically based on the time of publishing as well as forced in some controls and no article can appear on a page twice, yet controls have to have predefined number of links. May not seem hard to do, but believe me once controls will start stealing articles form each other you’ll see why I listed it as a main feature.

First thing to give the credit where it’s due – let me enumerate the good sides of using EPiServer in the scenario (the parts that we found particularly useful):

• EPiServer provides a beautiful interface to the editors. Both for editing pages and organizing the content.
• EPiServer provides a great infrastructure for us to plug into it with property types, and GUI plugins
• EPiServer allows us to use as much or as many of its elements as we need – from our point of view we mostly use it as a repository and pretty much ignored all of its custom controls and a great deal of its APIs (which I’ll explain later why.

The list does not seem like a long one – but believe me – all of the points are fundamental to the success of the site! The editors love the UI, the developers love the extensibility and “pluggability” of the APIs. And the logical structure of the database allowed us for flexibility in skipping some APIs where it proved that a direct database call was beneficial.

The bad part is basically that the EPiServer API is slow for what we needed it to perform (the site can easily reach a couple of thousand simultaneous connections at peak times), if we wanted to use GetPage() for every link on the site we would be in serious troubles.  At our average of 155 links per page, this was a serious problem.

Also since we have a structure of the tree that is not directly reflected on the site, but rather we search by “categories”. The idea of the site is that it is a huge search engine that displays the freshest content content based on the facets it is tagged with. Using the EPiServer APIs we would have to use FindPagesWithCriteria() which in itself is probably the most disliked call speed-wise. Also categories in themselves do not support any metadata (there are no properties for categories). Needless to say – we had to implement our own code for this kind of creative approach and that’s what we did.

In effect, what we limited to the list of hardest abusers are:

• FindPagesWithCriteria()
• Getpage()
• GetChildren()
• and (mostly based on Mat’s article) use of dynamic properties.

Basically all the calls that return PageData or PageDataCollection are all potential candidates for heavy caching.

The main approach that we took in our solution is “cache the hell out of it, but do it smart”. Don’t cache PageData unless there is absolutely no other way. Cache links, page titles and data that’s potentially used on every page.

Also where needed and justified by the speed increase we reach directly to the database – skipping some EPiServer APIs (At this point this is just one call as we want the solution to be easily portable between various EPiServer versions).

More (and the solution) coming shortly…