Symphony.

Creating CMS-driven websites for some years now, I keep on facing the same problem over and over again: Backend authors are arranging images, paragraphs and lists to create a visual representation of what they think is “the content”. This is happening regardless of using a WYSIWYG-editor (though it is the worst case), the WYMeditor or even Markdown. But why are they doing that? Because the given framework of data fields (called a “section” in Symphony’s nomenclature, right?) does not exactly match the content they have in mind when creating a new entry. This is where slice-based CMS really rock. You can create blocks of logical structure and the users can arrange them the way they actually need. (They suck in most other points, however.)

So my question is, how do your sections look like? :-) How do you achieve flexibility with your sections while maintaining a solid logical structure? Is integrating the Subsection manager the only/the best way to do that?

I think this really varies alot depending on the nature of the content the site is intended to present. Sometimes a section is closely tied to the meaning of the content itself, including fields that are meant to hold a very specific kind of content. Other times, fields are more related to the presentation such as different textareas relating to different parts of a page layout.

Essentially you’re asking when to allow ‘unmodeled’, arbitrary content as raw html vs. when to create sections & fields and add additional view logic. If you are doing the latter, then yes, the subsection manager is a handy way to do that.

There is no panacea in my opinion. It really depends on the type of content and who’s doing the editing. You might have a single entry that represents a “page” (such as a blog post) or you might have a complex page with multiple content types that requires a granular structure.

At the Symposium I showed some screenshots of one approach:

A page comprises multiple “components”. Each component type is modeled as its own section. We built a relatively thin UI layer that allows users to add components to a page and configure them in-situ. This complex UI would never have been possible in the backend natively, unless you really want to scare users!

Thank you for your helpful replies. And yes, I should have noted which kind of project I had in mind when asking :)

The components approach is pretty smart, by the way. Thanks for sharing.

Nick, the integrated editing is fantastic - how are you calling through to the backend to grab that UI? (I assume that you’re calling the backend for the UI?)

Yep just loading the backend via a lightbox. By passing lightbox=true in the URL it triggers extra JS/CSS to hide the header and footer and make it more lightbox friendly. As I said in my presentation though, this is purely a hack, and not something we want to encourage too much ;-)

But on that note Nick, using your Section Schema and Form Controls is a good method to rebuild the backend as a user friendly ui.

Even though the Symphony admin is slick, I would never want users to see it. The people I build sites for are so computer illiterate that I have to build a wizard like interface for them.