[rachelandrew]

We already essentially do that sort of thing within Perch (see Blocks: http://grabaperch.com/blog/archive/introducing-blocks). However people still want to be able to add inline links, make things bold and italic, add headings and so on within the content fields.

One could - within Perch - make the editing incredibly granular with Blocks. We find though that whatever we do with structured content, a lot of customers will still just go with the "big textarea and a WYSIWYG".

[zapt02]

Having worked for a long time with block-based editors in systems like Drupal and WordPress, We've found that there is a big limitation - the editor is detached from the authoring experience. We're moving on to front-end editing, and I think most CMS systems will have to do the same to stay competitive in the larger scope of things. What are your thoughts on front-end editing, more specifically, how could one apply a block-based mantra to frontend editing?

[drewmclellan]

Front-end editing is one of those features that sounds like a good idea, and makes for good demo, but has some fundamental failings.

1) It sets up an expectation for the user that they are editing content on a page, as if they were editing a Word document. But they're not doing that. They're editing content in a system that then happens to be output on that page. It might also be output in other places on the site, maybe in different presentations. This causes weird spookiness-at-a-distance issues where making a change in one places has unintended consequences in another. Essentially you're presenting a metaphor of editing content on a page, but the metaphor is a lie.

2) It encourages the user to think about how the content _looks_ not what the content _says_. This is the same fundamental issue with WYSIWYG editors, where the user wants to make things big and red and underlined. And blinking. The role of a CMS user is to create content. The role of the web designer is to set up the system to publish that content in a way that communicates best according to the site's objectives.

3) The way the page looks when someone is editing on a big screen isn't necessarily how it looks to all visitors to the site. Even saying "this is what your site looks like" is a massive oversimplification. It's not even straightforward to define what a 'page' is on a modern site, and that's only going to get more complex as the web evolves. Trying to tangle your editing interface in with an ever increasingly complex presentation layer is setting the user up for a world of hurt. And lies. Hurt and lies.

It's simply not sustainable, nor a good idea to try to combine your content management and your presentation layer.

[zapt02]

1.) There are some pretty nifty frontend editing demos that show you what the site will look like on desktop, table and mobile at once, I don't see that as a big problem. Don't really agree with it being a metaphor since most front-end plugins literally make the actual content editable on the frontend.

2.) Agreed on the formatting. But you can limit content editors by restricting the available tools and formatting options. As for the looks vs says, I think it heavily relies on the person. Some people are visual beings and perform better when they are seeing their page being built as opposed to created in a detached vacuum.

3.) #1 adresses this in part. As for complex content, we've had pretty good feedback on using blocks with visual previews on the frontend. There are issues, such as very large blocks having problems with drag-and drop, but I think these are just hurdles.

From a programmer standpoint, I guess it would be nice to detach the content from the presentation, but working "IRL" with business owners, creatives and journalists I hear almost every day about the "complicated systems" that people want to get rid of, opting for a simpler, visual experience.

[teleclimber]

Right. In the thing I am describing the editor would handle block-level things as well as inline styles and links -- all in one contiguous editing surface.

It's true though that non-technical users have an amazing ability to fall back on the most primitive tech just to get the job done.