I can smell your CMS at Fronteers 2012

This varies a lot in practice, Alexander. But ultimately the client needs to be totally on board with the decisions being made about this critical technology choice. I have found that the levels of expertise, opinions and influence vary dramatically from one client to another and some arrive with preconceptions about what CMS they want to use. In many cases this can be something which is already decided or in place in the client's infrastructure so you have very little chance to change that. Others are more willing to enter a discussion and allow you, as the domain expert, to provide some carefully considered recommendations.

Good point, Robbert. In fact I mean both. Each type of input has different implications in terms of introducing CMS Stink, but both can be problematic. WYSIWYG tools which allow the user to edit the content while seeing the formatted output of their work are particularly bad as they introduce all manor of inefficient code artifacts without the user being aware of this.As they often include wide formatting options they also allow the content editor to deviate from the design which can rapidly degrade the designed experience of the site.

I wasn't aware of that, Martijn. I gather that this is something that is improving in .net but not all CMS platforms built with .net will adopt the improved pattern right, away so you may still find this kind of smelly code finding its way into your work.

Wonderful! They should update the implementation on their own site to make use of that. Enterprise platforms that I have encountered often bring a high level of technical debt or friction to migrating. I'm not sure what effort is required for EPiServer to upgrade their own site to use their own latest best practices, but I'd like to see that happen.

Darius, I'm sure that there must be several, but there is only one I know of at the moment. Perch sets itself up to be a "tiny CMS" but I think that it has a lovely and powerful approach. You begin by creating your site as static templates and then declare areas in those templates which should be dynamic and managed by an admin application. This action builds an appropriate administration area for you while leaving the output untainted by CMS Stink. This allows you to have complete control over the front-end development and enhance the site with various types managed content.

There will be limits to the projects where this is appropriate, but I'd argue that it is a viable solution more often than you might imagine.

SilentImp, Ideally it is good to separate content from style from behavior as we have learned with HTML, CSS and JavaScript respectively. You have a good point though, that with the ability to author or generate HTML, content editors can indeed influence the style of the content. This should really be limited to using defined styles though if we encourage them to adhere to structured markup rater than giving free reign over all.

For total separation of content from style, then systems that allow only plain text input into defined content areas might provide an answer, but I find that those can be just too restrictive at times and have very particular useful scenarios.

Yes indeed. I think that one of our responsibilities in agency work, is to determine when WYSIWYG is beneficial and when it is detrimental. Projects are seldom the same and there are some cases when we can argue the point better than others. I believe that we can use examples of the effects of the use of WYSIWYG editors over time with case studies and examples to try to make the point. Presenting effective alternatives and demonstrating the different potential workflows and results can be helpful.

I have found it very hard to persuade clients who demand WYSIWYG to reconsider. Only in a few cases have I been successful. I'm hoping that the community as a whole can help to compile case studies and communicate the alternatives.

Halp!

Norbert, I think that Markdown is well within reach of most people who you would be comfortable being responsible editing content on your site. Accompanying it with a simple guide to content strategy, style and markup syntax can be a huge help.

There are many wiki markups available out there, but I like the way that Markdown is so well understood and supported.

I have also had some good success with systems which are even more prescriptive in terms of what they allow people to enter as text. By using something like Django or other suitable MVC frameworks to build out a very structured input for content into templates, you can get the the point that you are just allowing people to enter text into the sections that you need. This allows for a complete separation of style and content but can be a little bit too rigorous for some projects.

I have to say that I'm not a fan. I can see the temptation to allow users to navigate around the site as normal an then switch to a mode where they are able to edit the content that they see. This gives good context to the editor about how their content will appear but does a poor job of protecting the designed experience. This kind of interface always seem to add a lot of UI hooks and other CMS smells into your code which make optimising and being future friendly incredibly hard.

Norbert, this is a tough one. I think the biggest key to success here is complete buy-in from the client. Unless they are totally on board with that approach to the project, then you can't run it in a truly Agile manor. I've been fortunate enough to work on a couple of projects where that has been the case, but it is very rare. The desire to define upfront the cost, scope and deadlines makes a true Agile approach impossible.

At R/GA we do borrow aspects of Agile development and tailor those practices to work within the constraints of a traditional waterfall engagement. Finding those aspects of Agile that work for you can be helpful but they tend to shift depending on how you work with each particular client.

Wes, Randy, I think that a good CMS should be totally transparent in the front end. As such we should be able to adopt the kind of techniques that are emerging in front-end development to support a responsive design approach. Stripping out the UI hooks and other smells left by many CMS platforms can actually help to enable a responsive design.

One area of a responsive approach which gets a little overlooked does have a burden on the back-end however. Rather than delivering the same large image assets to all devices and then scaling them down in the browsers to fit the screen size, it can be important to have smaller versions of image assets and then 'upgrade' them to lager images where appropriate. Ideally the system would support the generation of different sizes of the automatically to support that.

Varya, Yes, but this is a tough problem and I think many large platforms try to serve many masters and provide solutions to each and every possible problem that they can imagine in this area. As a result they often focus on the capabilities without giving any consideration to front-end performance or the kind of challenges that front-end developers need to overcome.

I think that this is a symptom of front-end development not being given the respect that it deserves. Historically platform developers seem to have considered the front-end development work as the 'easy last step' in producing a system and so not given it the attention it needs.In recent years we have come to appreciate the complexity and craftsmanship involved in front-end engineering and I think that we need to highlight that realisation, which is one of the motives for me to give this talk.

Yes Victor. There are many frameworks out there that can let you introduce your very own code smells into the work. Even with the best tools, we can always find ways to do a bad job - I've been guilty of that myself plenty of times in the past! The trick is in recognising the smells we should avoid!

Thanks SilentImp!

You can get to the slides on speakerdeck where they are also available to download as a PDF. Other coverage from Fronteers 2012 is collecting nicely on the event coverage page at Lanyrd. A video will soon be available from the nice folks at Fronteers.