I know that this is only my second post this year and I haven’t done one since November 2010. I’ve been a bit busy lately and with the holidays, it was tough to get my head on a topic and write about it. Anyway, I’m getting back to it and I’m hoping to find out what kind of topics you’d like to hear more. I’ve been all over the place (but maybe that’s what makes you read my blog) from simple hacks that I do, actual real-life best practices, to business and technology insights.
Here are some ideas that I can explore and blog about:
- OMS and Analytics
- More Sharepoint
- Site Creation Best Practices
- Other CMS vs Sitecore
- Azure
- New Sitecore Features
- Selling Sitecore
- Sitecore Beyond CMS
- System Integration
I’ve also been contemplating of writing a comprehensive e-book that guides a developer from installation to deployment. The audience would likely be more for new Sitecore adopters but I’ll put enough best practices and techniques in there that I hope seasoned Sitecore technologists would at least read and give me some feedback.
I don’t have a set date but I’d like to hear your thoughts on what you’d like to see as well.
As a Sitecore specialist and interaction designer I often wonder why Sitecore is always mentioned on social media as a master piece of CMS. In my opinion it is only partially. Yes, the technique behind it is very flexible, but the system itself is not user friendly. Not by my educational background, but mostly by my (internationally big) clients. Especially the OMS expects a certain template and presentation structure in order to use it properly. Direct consequence of that is that the content editor mostly get cluttered or again, not user friendly and less flexible. To summarize, my question for you:
ReplyDeleteWhat is the best practice for template creation and structure of a regular content tree to keep the system as clear and clutter-free as possible, but with maintaining the possibility for deploying the page editor and OMS?
We've worked with clients that have thousands of content items and their system is still easy to use and the site still performs well. It's a combination of content structure, modeling, and automated actions done behind the scenes. Some techniques include, for example, using "save" event handlers for news items to automatically save the items in a structured tree (i.e. Year/Month/Day). This technique work fairly well even in a Page Editor. So, I guess to quickly answer your question, you really need to put some time on modeling your content but balancing structured content (i.e. news articles and events) with simple pages that may be treated as general pages. Then, you should use event handlers and insert rules to help in governance according to your rules.
ReplyDeleteI don't entirely get your question with regards to the OMS. We've worked with it and we've been very happy. You do need to realize what you're looking at since it really doesn't replace a Web analytics program like Google Analytics and Webtrends. Instead, it's something I call a CMS analytics which is more content-based instead of just URL-based. Although I still need to further explore OMS's capabilities and possibilities to relate collections of content items that are shown on a Web page and how I can infer better analytics. I know one can do custom tracking, but wouldn't it be great, say, to have your 5 homepage feature content and track how many times they show up as well which ones have been clicked. I'm guessing I can do goals, but not sure how that would work yet.
Anyway, back to the best practice. When it comes to template creation, it's essentially an art but you should look at it as if you're a DB administrator normalizing data as much as you can but understanding the implications with performance, security, and scalability. It's basically the same idea. So, if you think CMS that way, you know that clutter (or orphan content) are inevitable but with Sitecore CMS, you can create those rules and event handlers to help you keep content reliable (almost like event triggers and cascades) but more powerful and customizable.
Thanks for your quick and solid answer, Marco. The way you describe it is essentially how we - being the agency that I work for - handle template structure. Let me give you an example:
ReplyDeleteLet's say that we have a news article. It is an article covering product X which is part of a bigger subject Y. Our page contains a regular head with main nav, a nice visual of X, a page title and some release info. The page is mostly built in paragraphs. Each paragraph can contain an optional paragraph title, some copy and an image. Also on the right side we have a comfy sidebar that enables the Sitecore user to add up to N kinds of widgets. From a form that orders a brochure to a simple banner deep linking to a generic page.
In this case we would follow much like the following construction:
/Sitecore/content
Home
Centralized-sidebar-elements
Widgets
Widget-1
Widget-2
Banners
Banner-1
Banner-2
News
News-article (this would be the actual article page)
Copy
Introduction-paragraph
Additional-paragraph
Follow-up
Conclusion
Sidebar
Widget-element
Banner
Given this tree structure, we do the following: the article page node contains all basic info about the article. The header visual, page title, some meta info, etc. That would be the head presentation. Second, we have a paragraphs presentation with a control which simply loops through all sub nodes in the branch, being the paragraphs. Lastly we have a presentation for the sidebar. It hails all sub nodes in itself with a control. The user adds a sidebar node to the article branch and can select on that template what banner or widget he/she would like to display.
This way elements are centralized and can be re-used for multiple articles, or simply throughout the entire website. The paragraph method gives the user a clear understanding of the page structure. Sorting the paragraphs is done easily with the sorting tools of Sitecore. I think, from where we stand at this moment that it doesn't get much better than this, tree structure wise.
There is a major but though when it comes to OMS. OMS is stating that multivariate testing and behavioral targetting is done on presentation level. The presentation for a certain element remains the same, but the data source is changed based on specific rules or variations. Now the way i see it, this inflicts the way I handle the structure. Looping through sub nodes by a control for paragraphs isn't understood by OMS, thus should I flatten out my branch and create one article template containing the basic information fields, 15 fields for paragraph copy, 15 fields for paragraph imagery, 15 fields for paragraph titles and endless input fields for the sidebar widget? That seems highly illogical.
It would be great if you could grant some insight about this matter as I couldn't seem to get any reliable answer on it in all the cookbooks there are out there. Sorry if my content tree paradigm is a bit unclear. Rather hard to come up with a simple example, though illustrating a somewhat complex structure. Typing this on an iPad at 2AM isn't helping much either ;)
Thanks in advance!
Banner
Order-brochure-widget
I'm not entirely sure if I understand the structure above. Is there a way you can send me a screenshot that shows that. If each of those are actual content item (tree node), then I'm really concerned because of the level of granularity seems very atomic. If each node (consequently the data template) only contains one field (or even two), then you're probably normalizing it a bit too much. Remember about my analogy with a database. We sometime normalize it for flexibility which is what you're doing here, but sometimes performance and manageability becomes an issue. That's why data warehouses uses star schema (which are normally aggregated data) and not full transactional data because it would take too long to analyze. Anyway, I guess my point is that you'll need to investigate the level of control you really need to give your users. Is it really necessary to have each paragraph as node for the sake of sorting and reuse? I think the RTE is pretty clear on the order of the paragraphs. With re-use, I don't know how you can really re-use paragraphs as they are normally contextual. If you really need paragraph re-use, you may want to investigate dictionaries.
ReplyDeleteOf course, the obvious suggestion so far is why not put all those various elements of an article as part of the article template instead of separating them? You can use sections and custom page editor to make the content entry easier. You can still have banners and widgets in a central location, but reference them in your template through field(s).
As it relate to OMS and the way you think you need to create your fields, I'm not sure if you need all those fields. Why not let the author create those paragraphs, titles, etc. within the RTE? Is it because of style control? If so, then use a combination of RTE Profiles, snippets, CSS classes, save validations, etc. to ensure compliance. Of course, a bit of training goes a long way.
With regards to OMS not understanding your rendering logic (i.e. loop through sub-nodes), I think that it should. The MV Test variable should only provide the source and go from there. So, if it doesn't work that way, I'll let Sitecore know for sure. But, let me investigate first. By the way, is your rendering code in XSLT or user-control?
PS: Since this has been a long post, after you feel like you got some direction, do you mind if I copy/paste our conversation as a blog post to give it more visibility and hopefully help others as well?
Hi Marco,
ReplyDeleteI'm sorry for my absence this week. Your contribution is much appreciated.
Our experience with our clients is that most of the Sitecore users are actually part product manager, part webmaster. Or an ICT manager, that has basic knowledge of HTML, but lacks the design and layout part of a webpage. The point of direction you are making towards the RTE seems very logical, but in our experience that ends up with pages that have faulty imagery, markup left overs from copy/pasting or turning pages in to one big WordArt and animated GIF jungle (bit exaggerating here ;)). My point is that we try to maintain a company's CI and maintain the best HTML markup as possible (for cosmetic and frontend code reasons, but also for SEO). Mostly, when it comes to imagery, the RTE is to difficult for the client. Think of lightbox classes that need to be added to img tags, CSS classes and dimensions that can differ from image to image. All these specific settings is something that you don't want to burden your client with. We have high-end clients, many multinationals, with adequate personnel to maintain their website. Your proposal of using snippets and RTE profiles is something that we are starting on the last weeks, but that seems rather tedious. With every change to the layout, we need to alter the profiles and validation too, which is twice the work than changing only the front-end code.
Therefore we maintain a tree much like described in my previous post (screenshot: http://bit.ly/gPJfxV ). We have a content page that handles the basic information of a page (title, header, meta info, etc) and has multiple presentions on itself handling the different divs on the page. Each presentation is fed by its subnodes and/or by the node itself. The paragraphs presentation is looping through 1 till n paragraphs (also note the different types). This means that the user also maintains most of the lay-out from a content perspective and not by presentations. By changing the sort order the page changes, but the overall layout remains. The sidebar presentation is handled by a subnode (named 'Right-Column') where the user can add panels on the spot, but also link to panels that are stored in a specific place in the tree.
This approach is indeed very atomic, but actually lowers the knowledge base for the user in the content editor. We get good feedback on it.
Concerning the Page Editor mode and OMS: since they work on a presentation level, they allow users to simply add presentations to placeholders or to switch datasources for MV purposes. In our case, since we our placeholders are mostly compiled by code, users cannot longer add and remove presentations within the placeholder. At least not in the most user-friendly way as Sitecore poses. As I see it, in contradiction of our structure method, Sitecore requires us to flatten branches to a single node, housing the basic page parameters, all widgets (1 till many per different widget), banners (1 till many), 1 RTE editor for the content or alternatively paragraphs (1 till many). There will be an incredible information load on the templates, but since the users should use the page editor mode anyway that shouldn't matter.
Basic question: since we want to bet on both horses and not only the prefered usage of the content editor or the page editor, there should be some way of compromise between these methods?
P.s. Yes, of course. I am deliberately keeping this information generic and non-personal due the privacy of our clients. I am hoping for a nice outcome, which could help more agencies and implementation experts out there :)
That's a tough problem to solve. Needing that granularity does bring a level of ease-of-use and compliance which is great for deployments with large author base, which I assume yours do. So going back to your 2 original issues: number content items and OMS support of your architecture. With the # of content items with the way you have it is probably going to be a problem for any CMS (I know that's not really an answer) but if there's a way to hide those content nodes that make up the main node, that would be the ticket in one way. For instance, you can create something similar to what the Template Manager does to where it has it's own editor and creates the field content items underneath it. So, instead of creating those under the main content node, you can may be hide that in a hidden/secured global area to where you refer to them. The hard part would be to build the content entry UI but it can be done.
ReplyDeleteThis still doesn't answer your OMS issue and may actually pose more problem. So, I say that you may want to extend OMS on how it renders MV tests.
Thanks Marco, although it is indeed not an answer :) Questions pose new challenges though. It's good to know that I was on the right path anyway.
ReplyDeleteI'm not fully sure though what you mean with the analogy of the Template Manager. Do you mean that the structure should be fully taxonomous whereas you would centralize all specific datasources based on their type in a resource pool and link them from specific content nodes in a simple tree. The simple tree would be the site structure as it is built on hierarchy. So by adding a banner presentation in a placeholder of a product page, you would actually create the banner node in the resource pool at the rest of the banner and creating a link ON the product page node? So that the system would recognize it as a field on the datasource itself, instead of a sub node? Basically the same thing as what I did with the banners and widgets in my screenshot, but then on the content page itself instead of adding the teaser box sub node.
What I meant with the Template Manager is how it gives the user a different UI to create a new template. So, you can essentially do the same by giving the users a new UI, for say, a new article. So, to the user, it looks "easy" but in the background you are actually creating the various content items (like banner, paragraph node, etc). But instead of saving it under that main article node, you're saving it elsewhere. I'm not sure if that helps because part of the problem is really OMS.
ReplyDeleteThanks for delivering a good stuff related to Sitecore, Explination is good, Nice Article.
ReplyDeleteSitecore Online Training