A colleague sent me the link to Rachel Andrew’s talk at the Smashing Conference, 2012 in Germany. The talk she gave was on the future of the CMS. I want to first say what a great talk. She hits on several key points in a style that made me think and laugh at the same time. The first third of the talk discusses structured content. Structured content is the idea that each distinct concept that we want to show users is entered by a user as a separate piece of content. Rachel uses an example of a date. Dates, locations, times, headings, sub-headings, ancillary links, etc…

I am primarily a Drupal developer these days and during the start of the talk I kept nodding my head and telling myself, Drupal can do that. While Drupal can accomplish this it can be a fairly poor user experience. Each piece of structured content is basically a form field and for a small piece of content like a blog post, there could be 5-10 fields. To solve this we can try to help the user by pre-populating the date, time, location, etc… She goes onto present three key points of what a CMS should do in the future.

1. The CMS should help content editors make good decisions.
2. The CMS allows the designer to make semantic decisions so the editor doesn’t have to.
3. The CMS protects the design and architecture decisions made for the site.

I would like to say that a properly constructed Drupal 7 site very nearly presents the future CMS now. However, Jeff Eaton of Lullabot just published an interesting article, Inline Editing and the Cost of Leaky Abstractions. How will structured content survive inline editing?

“Structured content is not a silver bullet.”

Jeff’s article and Rachel’s talk both emphasize a careful balance. The colleague who sent me the talk and I discussed this as well and balance is the actual hard part. We can structure everything as unique fields and attach metadata behind the scenes, etc… but it then borders on insanity as you look at the form. Again we abstract some of the complexity and hide it from our user, that is part of our job but for complex data a big form is overwhelming. Big forms are nothing new and many strategies exist to solve them, and using contextual overlays we can break the forms down in Drupal into manageable chunks. This is not yet the norm.

“Avoid directly inserting HTML into content.”

I applaud Rachel for discussing this topic. I do not agree that markdown is an answer, mainly because I have always had a hard time with it. I like the idea of using a WYSIWYG type entry system for users where they can highlight some text and italicize or bold a word. Not because it is familiar for users but because it is fast. However, this again comes back to a balance. If I strip all HTML or do not give a user a chance to emphasize text in anyway, I must ensure the design accounts for this. Perhaps the only bold text is the subheading for the title of the page. The only text that is italicized is the image caption. I think this is brilliant but difficult for me to achieve.

Here is to the future CMS!

Thank you Rachel for discussing the issues above. While it may be difficult for me to achieve the balance I have discussed, we all need to struggle to find answers to these issues. The web will be a better place for it.