Architecture, Sitecore

Content and presentation separated – Does it make sense?


Often I hear that Sitecore separates content and presentation completely – In fact it seems that it is a key selling point. Lately I have also seen other CMS vendors promote the same idea. But I must admit that I don’t understand why it seems to be so important. Is it because of reuse of content? Is it because you want to be able to present the same content on different devices such as iPhones, PDAs etc.?

But…  Does it make any sense?

·         Most of the clients we have been working with prefer to use the content editor and not webedit. To ensure that content editing is user friendly and intuitive, most of the time we construct solutions, where the content structure and hierarchy is the same as how it is presented on the frontend. This enables the editor to find and edit content in the same manner they find the information on the frontend.

In this matter it makes more sense to bind content and presentation structure together.

·         You seldom want to use the same content structure on different devices. When constructing sites for mobile devices, you probably want to have a simple flat hierarchy, which is different from your normal site.

Therefore it makes more sense to me, to have two different structures optimized for the presentation on the different devices.

·         Often the editors want to be able to edit the presentation. If they create a list in a rich text, they probably want to be able to decide how this list is presented – hence you bind content to presentation. This is allowed in the rich text field. By nature WYSIWYG editors is bound to presentation. What you create is what is presented. Should you avoid rich text fields completely?

·         If content from rich text fields should be independent from what devices it is presented on, it requires editors to consider this, when they create their content. For instance a table with a lot of data expanding over 320 pixels wouldn’t look good on an iPhone, so the editor has to be more aware of the technical limitations of the devices or limited to use memo fields.

All in all I find that you on some level always want to bind the content to the presentation, allowing more flexible content and giving editors a more intuitive way of creating content.

I agree that you can construct a Sitecore solution that separates content from presentation completely, by developing a solution consisting of a big repository of memo fields, which can be pulled on to a presentation item… But this wouldn’t be very user friendly.

So why is it so important to separate content from presentation and does it make any sense?

Standard

26 thoughts on “Content and presentation separated – Does it make sense?

  1. rasmus says:

    I believe that the reason to separate content from presentation is technical related – where the use of a WYSIWYG editor or rich text is usability related. The technical developer would like to separate content from separation so data is only persisted one place for more or less the same reasons databases are normalized. Editors would like the editing to be as convenient as possible and thus have the content as present / available as possible.

    My personal opinion is – Yes, it is very important if one cares about technical maintainability and integrity of large amounts of data / content. I do believe that Sitecore supports separation of content and presentation, but I also believe that many Sitecore solutions ‘hacks’ the templates with WYSIWYG fields or rich text fields. The DB equivalent of the WYSIWYG field is one large table. Who likes that? The end user does because he/she do not have to care about maintenance and integrity of the data.

    The all memo field solution is in itself agreeable not very user friendly, but that resembles using a DataGrid on a table. That is not very user friendly either and few accepts that as a viable solution to editing data when it comes to end users, right?

    Sitecore has the notion of templates, but most Sitecore solutions I have seen does not take advantage of that when designing presentation layer templates due to customer demands and time / cost issues I guess. To allow for a cleaner separation of data and content, it would be a technical better solution to make use of more fields instead of one big rich text field.

    My point is: separation is important for technical reasons, but it is not Sitecore that ensures the separation but the architect of the Sitecore solution that does. Sitecore only supports it.

  2. rasmus says:

    Follow up: If the all memo field solution or other solutions alike are not user friendly enough, then it is the lack of custom user friendly GUI components that provides the bottleneck of the solution. This does not make the technical point of separating content from presentation any less valid. But then it all comes down to money – who will pay for highly user friendly GUI components when a WYSIWYG field is there to support all needs? I don’t know.

  3. Jens Mikkelsen says:

    Hi Rasmus,

    You are right about it being a technical better solution.

    But if you restrict users to memo fields and GUI tools, you will put constraints on the content. Often you see different sites with 100+ sitetypes with a picture to the left, to the right, a page with a table, a page with different amounts of different types of paragraphs etc.
    So the extra cost for the client is not only in GUI tools, but also the cost of implementing 100+ templates. This will again lower usability, forcing the editor to decide between a lot of templates.

    So maybe the question should be: Is it possible to make a solution, where content and presentation is separated while keeping the flexibility and usability clients expect from a CMS? And would it be to costly? Hence – would it make sense to do so?

    It seems that when the clients, I work with, hear the phrase: “Content separated from presentation”, they expext, that the content can be presented anywhere with any type of layout, and this conflicts with their expectation to the flexibility achieved with for instance a richtext fields.

  4. I tend to see it as a compromise. In the same way that perfection is a direction, not an (achieveable) end goal in itself, we still pursue it. However we also stop normalising our databases at a certain point. Same when programming… we may make objects, but rarely do we find it necessary to make every single property an object of its own – usually the built in types do “well enough”.

    Separating presentation and content is no different, in my opinion. You take it as far as it is practical – and more importantly – beneficial for everyone. I don’t believe for a second that creating more templates (as an alleged side-effect of this separation) is something that makes the solution cost more for the client. More the opposite. Just like making c# classes in your code doesn’t cost more – it ends up saving money for everyone.

    The RTF is the compromise. When it is no longer practical to continue the separation, RTF acts as the glue that binds the technical implementation with the remaining user requirements.

    All that aside. In my experience, you gain a lot of value from separating content from presentation. Not in the “multiple device” scenario – I completely agree that this is the exceptional implementation rather than the norm. But it is gained when you work in multi-site solutions – clients who have 3-4 or many more websites; all related and drawing on parts of the same content; but completely different in their layout/presentation.

  5. Jens Mikkelsen says:

    “clients who have 3-4 or many more websites; all related and drawing on parts of the same content; but completely different in their layout/presentation.”

    I may think that this is what Sitecore want to signal and achieve with the statement, but I just don’t get why this is so special for Sitecore and a selling point (same goes for other CMS’ that promote it). For me this is more a question of correct html and use stylesheets.
    With my somewhat limited knowledge of other CMS’, this might not be possible in those, or?

  6. The way I see it (working on Sitecore UI) is that there’s more work to be done. Interfaces should be easier, creating and using solutions that separate content from presentation should be easier as well.

    But even now I think there is a huge number of benefits. Like a well structured and designed code makes it easier to maintain and improve your app faster, having a well structured website allows for faster and bolder updates, changing directions and implementing new ideas (but I can see how too many restrictions for editors can do exactly the reverse).

    I haven’t done a Sitecore website in a while, unfortunately, so I find this post especially helpful

  7. Oh I think it is, to some extent. I wouldn’t dare to go in and directly compare where Sitecore is positioned in relation to competitors in this area however.

    But I do understand why it is put forward, and you point this out yourself. It’s a selling point. When purchasing a CMS, many clients start their preliminary work by having a loooong list of features drawn up – marking each feature “absolute must have or the world will end”, “required”, “could be cool”, “nice to have”, “not needed” (slightly ironic here, but you get the picture). And I guess partly because of all the “hype” surrounding “Separating presentation from content” (no self-respecting CMS vendor will NOT have this one in their feature list) – this one almost always comes up “absolute must have or the world will end”.

    And it makes sense too. If the solution is designed in a way that this separation is carried out at least to a tolerable extent, the client get to keep their data and could in theory migrate it to another CMS system. Obviously not what the vendor would want, but I can see why the client would.

  8. rasmus says:

    To Jens: I think the new question is more relevant and I assume we speak of solutions of considerable proportions. Of course it’s possible. Anything is possible with Sitecore 😉 But as long as an XHTML compliant WYSIWYG editor is used as a sales argument along with separation of content and presentation I would say it is impossible since the two concepts contradicts each other (as long as the editors persist the model and view together when persisted, as all rich text editor known to me does today)
    So I would say the answer to your question is to alter the clients’ expectations (that will happen in a million years) or to make a WYSIWYG editor that separates content from presentation. The problem is that Sitecore (and all other CMSs known to me) use rich text editors that do not separate content from presentation. So it does not matter how much effort a developer puts into designing the “right” Sitecore architecture as long as general consumer demands call for the greatest hack in CMSs as I’m inclined to call it. So put pressure on Sitecore to make a better WYSIWYG editor and problem solved 🙂 If they cut down on sales gimmicks such as w3c checkers etc. one could hope there would be time to make such technical and economical beneficial improvements.

  9. I can’t agree on that W3C validation is a sales gimmick. I see it as a reponsibility of the vendor to make sure all tools for optimal accessible websites are available. When our WYSIWYG editor lacks in delivering right HTML, we should replace it.
    But no editor in the world will never make a mistake. I think we’ve done a better job on suggesting a fix instead of a blackbox fix button.

    I don’t see seperating content from presentation not as something particular for different devices. It makes it easier to maintain your sites, especially when your controls change more often.
    Beside of that, have you ever thought about the option to add a variable to the definition of layouts e.g. a sitename? This will give you the power to vary layouts by site and templates. A powerfull combination. Keep such things in mind.

    As a salesargument it’s a strong thing because lots of our competitor stick to page driven model which doesn’t allow you to use content as it is meant: to construct any kind of content. Not binded to a particular model.

    But as always, I invite you guys to come up with better suggestions for our product. As you can see on a regular base, Alexey, Lars, and all the others think that the community opinion is more than worth to consider. So if we lack in some way, contact me how to change it and I’ll make sure our R&D team will put it on the list to discus.

  10. rasmus says:

    I’m sorry for my “attack” on Sitecore. My tone and phrasing is uncalled for. I fully recognize the sale argument, but that does not make my life easier as a developer that would like to guarantee data integrity and maintainability in a larger enterprise solution.

    I do not agree that it is the vendor’s responsibility to provide all tools for available optimal accessible websites. This is a sales argument rephrased as a technical argument. It should be the developers’ responsibility to produce solutions of highest quality and the vendors’ responsibility to support this. One “easy” way to do this is by including already made 3rd party tools and claim: No other tools available are better. I can agree that no other CMs I have seen can do nearly what Sitecore can and as good as Sitecore does it. I would just like to see Sitecore focus more on finding solutions to problems and be more technical innovating than focusing on providing “all the others have this so we should too” sale arguments. I was presented with the validator by a very proud Sitecore employee, and while I think it is a great job done on integrating the validator in Sitecore I would rather have been presented with new improvements made “under-the-hood”. For example like: We have written unit tests for most of the new API to a higher degree than ever before, since we have had problems with change in API behavior that resulted in run time errors in some solutions that we did not know of before it was reported to us. Or we did not have time to include the w3c editor because we were too busy testing the performance of the user database with 100.000+ users since it has given us trouble before even though we did not think it would.

    To get back to the point: What decisions have been made in other solutions that worked both technical and usability wise? And why did they work. Are there any common scenarios where one “philosophy” should be chosen over another? How complex should a solution be before technical arguments should be taken more serious than usability arguments? I would like to know.

  11. @ Rasmus. Isn’t this, at the end of the day, always a costing issue? Just remembering to factor in ALL costs – i.e. the total TCO – not just “how little can we get away with and actually get paid?”.

    On the whole topic of separating content from presentation however, wouldn’t we all be better off with a partner-configurable WYSIWYM editor? (http://en.wikipedia.org/wiki/WYSIWYM). Or at the very least, shouldn’t we as solution suppliers at least take the effort of taking full advantage of the product we are delivering?

    Now in a perfect world, I would never ever let the client “at it” in a fully standard-configured Sitecore Rich Text Editor. And I don’t think you are meant to either – really. But I think we are all guilty in some shape or form, of delivering a site to a client with the standard “default.css” and standard buttons/settings in the editor; just as they shipped from Sitecore.

    And every time I do, I feel this icky feeling of it just being plain wrong 😛

    We are SUPPOSED to configure this. Replace the CSS with something that comes close to the CSS in place on the final site. We are SUPPOSED to configure the RTE – get rid of the Font Dialog boxes, put in a dropdown with selectable classes (like Word, where you choose Heading 1, Heading 2, Body Text and so on). We all know this – or at least I think we do – yet it doesn’t get done very often in my experience?

    Maybe we need to look to the reasons of why not. Is it too hard? Well, technically (and therefore as far as Sitecore can take us) – not really. But in the real world, there’s people who do markup. They don’t think “Sitecore Sublayouts” very often. Then they make CSS. More often than not, they think than what they SHOULD be thinking (i.e. ) and so on. They are thinking instead of just .

    On this road to “perfection”, we need to encompass the entire process I think. From initial wireframes through html mockup and final implementation. And I haven’t many (m)any organisations/project processes where this has been mastered.

    Which brings us back to the compromise I mentioned earlier. Or at least it brings us back to this in my mind.

  12. And the silly comment tool took out my DIV tags above 😛

    Designers are thinking – div class=”some silly blue right hand side element on the front page” – rather than what they should be thinking – div class=”rhs spot blue”. And thinking – div class=”blue spot contentElement” where they SHOULD be thinking just plain P (tag).

  13. Jens Mikkelsen says:

    No doubt that the RTE is the biggest constraint on separating content from presentation. However I think that it has improved since the first editor i Sitecore 5.
    Still I often stumble upon irritating elements with the editor. The editor is getting used to a lot of to complicated tasks, such as embedding flash, javascripts or iframes. The client often expect this to work, because of experieces with Sitecore 4, and because of the possibility to alter the HTML directly.
    So there are still room for improvements on that matter.

    However I didn’t write the post to bash the RTE – it works ok, if you strip the most of the functionality. The post was also created, because I wanted to discuss or atleast say my opinion on the term “Content and presentation separated”. Why is this so important to clients and Sitecore?
    I mean, why create an information structure and hierarchy that doesn’t resemble the frontend/presentation? Why not keep focus on the usability of keeping content close to its presentation at some level?
    I think I have participated in one solution, that had one big repository of content which was pulled on a page/presentation with a set of multilists. It was very unpopular and the end users didn’t know how to use the system.

    The point being: Why not let presentation and content resemble eachother, unless it breaks the complete architecture and the basics of Sitecore? It seems that the solutions are much better for the enduser. I know this conflicts with the “Sitecore way” or at least the part about separating content and presentation – but I often find the other solution to be better and more satisfieing for the customer.

  14. @ Alexey. No there isn’t. It could be better in my book, but that’s because I find it too “general purpose” and would prefer a WYSIWYM editor per-project. But this goes back to the “in a perfect world discussion”. If I have a problem with customising the RTE it’s the fact that it often doesn’t get included in the project costing, and is ALWAYS sacrificed as the first thing.

    Sorry for not being clearer, but in this case I actually side with Sitecore – which some have come to believe i mostly don’t 😉

    @Jens I didn’t mean to side track your original post by bringing it down to a discussion about the RTE. But the way I see it, Sitecore sorts out the issue more or less as good as can be – and gives you the compromise of the RTE to “handle the rest”.

    As to WHY you should separate content from presentation – to be very honest… to me this argument is as self-given as WHY you should use (true) object oriented design when coding and never ever have code like “if ( myItem.Fields[“doShow”].Value == “1” ) ….” anywhere in anything you intend to put live. And that discussion is a very long one.

    But here’s a case that justifies it.

    Whatever website you build for your client NOW, today, you can be SURE (assuming you did a good job and actually KEEP the client and the client doesn’t go elsewhere) that the client will come back and ask for a new design. And when the client does, it makes a huge difference if you quote them £4.000 for “new skinning” as opposed to £14.000 for “redoing the site”.

    As professionals we owe it to ourselves (and certainly the client) to deliver solutions that are as true to the spirit of the CMS as we can. Even if it’s not always easy.

    It is always cheaper however, of this I am sure.

  15. @ Alexey – I probably wasn’t even clear enough even if I tried 😛 The RTE problem isn’t more of a problem with the RTE – than the “c# problem” is a problem with “c#”. To configure the RTE correctly for the purposes we debate here means, sometimes you need to “go back” on some of the choices made by the HTML creator and CSS designer (often the same person). Both these skills is not something I feel I master, and is often handled by external agencies… therefore they are very very hard to get changed. Especially if the agency delivered W3C compliant Triple-A compliant XHTML – WITH a slice of lemon on the top.

    In short, it’s more of a project managerial issue to start meddling with it, that a technical problem.

    And I don’t know the easy fix. Sadly.

  16. Jens Mikkelsen says:

    @Mark:
    I understand the basic idea about separating the presentation, but the one argument, that keeps comming up is: “Well what if the client wants a new design?” To me this is a matter of just altering the CSS (simply put).

    The second thing that comes up, is: “Well what about reuse of content?” and I still don’t see what difference it makes, whether the site is structured to resemble the presentation or not.

    But deep down I think we agree, because I don’t want to bind the presentation completely to the content or start making inline styling etc., I just wanted to question the always-correct-sentence: “Separating content from presentation is always the way to go.”

  17. @ Jens, I actually think we agree as well. Because I pursue “separating content from presentation” doesn’t mean I go “all the way”. I don’t think it’s practical to do so, for a whole list of reasons. None of which are really Sitecore, but more the reality in which web projects come into existence.

    I think it’s common today amongst many partners to have a /Home and /Global folder sitting side by side in the solution however. /Global often holding information such as “People”, “Offices”, “Products” and so on – many of which are pulled in and used as a sort of meta data. And this is very much a case of separating content and presentation.

  18. Hehe. The author of that strikes me as just a little bit naive. “But for a competent webmaster, building something like this from scratch can’t be all that hard. Can it?” 😉

  19. rasmus says:

    Oh yeah. Now that you point it out is is obvious to me that he indeed is very naive when he thinks that a webmaster can just put something like that together over night. He is also lazy since he has not done it himself over the past 14 years he has worked with web sites. I must have read it between the lines.

    You last comment strikes me as just a little bit naive.

  20. Pingback: Sitecore Fetch Squad » Blog Archive » Content and presentation separated - Does it make sense?

  21. I think there is a balance. I actually just rolled off of a big project where the client didn’t want the website to be coupled to the CMS, let alone the content, in case they wanted to change vendors in the future. Our web project had no references to Sitecore and we used Dependency Injection (IoC) and the Repository Factory pattern to tell the business tier which repository (data store) to use for which call.

    So the web page would just be asking for a Content Element, or a Promotion, etc. and would use the service layer to get it. Based on which data store was being used, a mapping layer would map the response from the DAL to the Domain Object (i.e. ContentElement, Promotion etc) and return it to the web layer. The client lost out on In-Context Editing, but gained in flexibility if they ever wanted to swap out data stores.

    We didn’t use Rich Text Fields, but we did have some robust templates that allowed the author to control the presentation. The Promotion Template would have some meta-data, such as Theme or Category, or Rotation – which the presentation layer would use to give the Promotion a completely different look and/or functionality. Our Content Elements allowed the author to assign 0 or more images to it to complement the text and choose the image allignement and functionality. The PageElements were smart in that they knew if they were in a skinny column or a fat one and would adjust their presentation accordingly.

    It was a bit more work, but it gave the authors the flexibility they were looking for without giving them full presentation control where they could make the site look really bad.

  22. Jens Mikkelsen says:

    @James

    This sounds very interesting!

    “Our web project had no references to Sitecore and we used Dependency Injection (IoC) and the Repository Factory pattern to tell the business tier which repository (data store) to use for which call.”

    Very nice! What were your experiences with IoC? What framework did you use?

  23. It was plain old .NET and config files to load the appropriate repository, but I am currently using StructureMap for my current client which I am quite fond of.

    The project I was referring to was in Sitecore 5.3 and we built by hand essentially what the Page Editor is in Sitecore 6.0. Now that 6.0 is out and the Page Editor exists, I am not certain that a complete decoupling of the web project and Sitecore.Kernal is the way to go (I wasn’t sure with my previous project but they were adamant about being independent from a specific CMS).

    The smart controls however that give the author enough flexibility without giving them a Rich Text field I am all for though. Instead of letting the Author’s say “I want a WYSIWYG editor”, try to understand exactly what they are trying to do with that editor and make it possible in the template / control. Re-use is much more likely to happen when the content is structured.

    If you take a look at http://www.snow.com/discoverourresorts/vail/landing.aspx : The ‘Did You Know’ template allows (bottom left) the author to pick a theme (in this case it is ‘snowy mountain’ or something like that), it also has meta data around the control that would have for example the Vail Resort checked. This specific ‘Did You Know’ isn’t necessarily assigned to this page directly, it may be the author has tagged this page as Resort = Vail and the ‘Did You Know’ is tagged as Resort = Vail and the ‘Did You Know’ control says “Hey Sitecore, could you please give me a random ‘Did You Know’ where the Resort matches the current page’s Resort?”.

    The same can be said for the header graphic. An author can simply tag the images appropriately and tell the control how many videos and photos they want shown, or they can specifically select the images and photos they want to show up – the photos, Did You Knows, Promotions and Content elements can be reused throughout the site. It might seem like a bit more work to give them this flexibility, but I think there would be just as much work trying to maintain whatever mess-ups the author creates with an Editor.

  24. Pingback: Content and presentation separated – part 2 | cmsnewstoday.com

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s