Structure Content in Preparation for the Future

The future is coming, and those who don't adapt often are left in the dust.  Being future-minded in your development of websites can mean the difference between being able to leverage new technologies and trends, or being faced with a total rebuild, which no one wants.

In this article, I’m going to go over some great principles for structuring your content and relationships to make sure it's ready for whatever gets thrown at it.

Separation of Presentation and Content

You've probably heard the phrase "Separation of Church and State."    It doesn't really mean what most think it means (where they believe that the Church should not be present in the state), the original intent of this phrase was that the State would not mandate a religion for the people, but allow them to be religious in whatever way they felt lead.  In the same way, the Content (State) should not be structured in such a way that mandates a single Presentation (Church), but should allow any variation of Presentation to leverage the content.  You may have some universal Presentation elements in the content, but they should be universal and be leverageable by multiple presentations.

Types of Presentation?

When I say "various presentations," what I mean is whatever means you wish to display or use the content.  Most of us are familiar with the Web presentation, it's what we all probably work with the most, but there are more out there, and their influence is growing.

Alexa, can you tell me the weather for today?  Hey Google, can you order me a pizza?  Do these sound familiar?  These are all presentations of content, and IoT (Internet of Thing) devices and personal assistant devices such as Alexa and Google Home are rapidly growing in popularity.

The Old and the New

The old way of content modeling was mostly around silos of data.  You had your data for your website, which you probably had presentation elements in with it, and data in some ERP system for your customers, and probably some other data somewhere else.  If you wanted your content used elsewhere, or wanted other content added to your website, you often had to write integration scripts to push or pull your data from one place to another, or manage it in multiple spots.  This caused many issues with content either being delayed in going from one place to another (thus content being out of sync), or general headaches trying to take the bits of data you wanted from the content while filtering out the stuff that didn’t apply.  This creates content friction.

The new way of thinking is omni-channel and presentation agnostic.  

Omni-channel is the idea that content is placed in a easily accessible location, and can be leveraged by a multitude of presentations.  Kentico Cloud has been a champion of this, providing a place where you can store content that is usable by any coding language or platform (through REST API), meaning something like Product information could be used by your website, a mobile application, or a Google Home.  Kentico cloud also provides SDKs along with its REST services, making it easy to use in newer technologies.

Presentation Agnostic is the idea that you should not put platform specific data in the model of your content.  The best way to explain the concept is with a bad example and good example of presentation agnostic data.

Bad Example of Presentation Agnostic Content

There is a recent client who came to us with a site that was built in Kentico, but was built in such a way that it was near impossible to maintain and was honestly horribly built.  The page type (the content’s model) for a product had almost 100 fields in it.  Yes, 100 fields.  And of those, only about 15 to 20 of those were things that defined what the product was, the rest were all presentation (banner1, banner2, CallToActionText1, CallToActionText2, etc).

What was even worse, is since the fields were so tightly tied into the web presentation, when they wanted to have a different presentation for the products depending on the type of product, the ‘solution’ was to create another page type with the new fields needed for the presentation, thus splitting products into 2 silos within their site, making referencing the data complicated as it now existed in 2 spots, just because of some presentation fields.

Good Example of Presentation Agnostic Content

One of my bigger sites I work on is owned by a global corporation that is made up of multiple brands.  These brands have products and documents that go along with it.  The content model for these products and assets are pretty strict, they contain only the fields that define what the product or asset is.  Title, description, product specifications / asset document, and the taxonomy that define them.  Some relationships exist as sub elements on the content tree (such as features), some as relationship tables (like what Image, Document, or Video assets are assigned to it), but each element’s model is really "What it is" not "how it looks."

Because of this, other platforms (such as a mobile application that allows users to look up product documents) easily integrated with our system as there’s no extra fluff to sort through, and we have 1 location of content that they feed off of.

There are a small number of presentation related fields (a couple Boolean fields on if certain things should show or not), but these fields are usable by any presentation, and they are limited in number.

There are other elements on the site, such as Banners, carousel items, and such, that we have already used in multiple different ways on the website as their designs change, but the content remains the same.

What do I do then when I need Presentation data?

Now let’s cover some real world examples.  It is very hard sometimes to build a presentation using only the base model of content.  In the first example I gave, a product may have multiple images or banners, or it may have some call to actions that a client wants to display on a product page.  These things aren’t really part of what a Product is, it is more what it has (relationship), or what a presentation wants to show.

Relationships (such as multiple banners that you want to show on a Product page) can be defined through one of these methods:

1. Place related items in the Content tree as children.
2. Use the Related Pages module within Kentico to relate one page to another.
3. Use a custom binding table.  
4. If you are in Kentico Cloud, you can use Modular Content elements to define these relationships.

Whichever method, once you have these relationships set, it should be easy to leveraged them in the Page Template / View (or whatever presentation model you have).

As for Presentation specific elements, things that are purely cosmetic for your specific presentation, you have a couple options:

1. If using Portal method (or the upcoming Portal in MVC), widget zones and widgets can be used to allow the user to add specific elements on the page.  Since this is only for this presentation, it doesn’t matter that these items aren’t shareable with other presentations.
2. You can add these presentation elements in a way similar to related items (ways 1-4 above), and display them using your Page Template or your View.
3. You can make “extending” presentation models that reference your Presentation-agnostic content item, and then contain all the presentation elements you need to properly render the content as you wish.  For example, you could have a Product model, then a PresenatationProduct model that points to the Product content and has things like a Call To Action text, and Call to Action link.
4. If the presentation elements are not dynamic, you can simply have multiple Page Templates or Views for the same content, each one containing the different versions of the presentation you want to give.

Where to Store Omni-Channel Content

Now that we have a good grasp of how we should structure our data, the next question is where do we store it?  Kentico Cloud or Kentico EMS?  This is a pretty complex question, as each platform has its pros and cons, and sometimes it's not an "either or" but a "both and" response.  Right now Kentico EMS still has more features, such as Content Staging, but that gap is closing fast as Kentico Cloud continues to grow in its feature set. Kentico cloud provides an easier integration interface, since it was designed to be Omni Channel.  As mentioned earlier, it’s pretty easy to interact through its, and the responses to the service are very fast.

Also thanks to the Content Migration API, it’s very easy to pull in content from Kentico Cloud into Kentico CMS if you need to leverage some of the other features of the EMS while still keeping the content in the cloud, and it’s possible to take Kentico EMS originating data and push it up to the cloud and keep it synced.

So when it comes down to it, take a look at Kentico Cloud, if the current list of things it can’t do over EMS don’t impact you, you’ll be more future-proof by placing it in the Cloud.  If not, then don’t be afraid to store it in the EMS and check out the various options to push data to Kentico cloud for your omni-channel applications.

Conclusion

Hopefully all this will help you all be ready for what the future holds.  It is never too late to switch gears and do things right, and you and your client/company will thank you for being future thinking and making transitions to newer technologies easier.  If you’re new to Kentico Cloud, don’t forget to try out their free demo, they even have a step by step guide that helps you get started.  Happy coding!