4 ms·

I would love to see a really good WYSIWYG-like thing that creates Markdown. I'm one of the founders of Perch (http://grabaperch.com http://grabaperch.com) and

I would love to see a really good WYSIWYG-like thing that creates Markdown. I'm one of the founders of Perch (http://grabaperch.com http://grabaperch.com) and we have almost 6 years of experience with Perch - and many more of creating custom CMS solutions before launching Perch. We've always tried to get people to write Textile or Markdown. When we were developing custom solutions we actually had pretty good success with getting our clients to use Textile, once we'd explained the benefits. With Perch we ship our default templates (which are really just samples) using the MarkItUp editor and set to use Markdown, and not allow HTML. However it's all configurable and we offer editor plugins so people can switch to using Redactor, CKEditor, TinyMCE or create their own editor plugin. In discussing this stuff with our customers who are developing sites for clients, it's not something that inserts HTML that they want. They just don't want the end client to see the Markdown as they don't think they will cope. I think there is often an assumption that they won't cope, but for whatever reason they end up installing CKEditor or whatever and it allows in a load of junk markup. This makes me sad. So, an editor that created Markdown yet allowed for some sort of preview of how things will look I can see the benefit of, if just to encourage confidence in not using things that allow inserted HTML.

teleclimber 11y ago
Personally I completely understand end-users for wanting a purely visual writing environment. No "show HTML", no markdown codes (and escape characters!) etc.. There is a reason desktop writing applications became fully visual three decades ago! The value of Markdown is that it defines a limited set of semantic blocks and text styles so that the markup and css needed to render the content is finite and predictable upfront. It seems to me this advantage could be achieved with an editor designed specifically with this idea in mind. The editor could be fully visual, but it would respect a pre-defined set of rules regarding content semantics. The editor could output an XML or JSON tree of content with semantic labels that you could then run through a markup generator. That way you have full control over the markup. Once you have that you no longer need to limit yourself to what markdown offers. Maybe you want to give authors the ability to create "warning" and "tip!" blocks when writing help manuals for example. If you define those blocks then the editor would allow the author to insert them.
- rachelandrew 11y ago
  We already essentially do that sort of thing within Perch (see Blocks: http://grabaperch.com/blog/archive/introducing-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".
  - teleclimber 11y ago
    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.
  - zapt02 11y ago
    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 11y ago
      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.

teleclimber 11y ago

Personally I completely understand end-users for wanting a purely visual writing environment. No "show HTML", no markdown codes (and escape characters!) etc.. There is a reason desktop writing applications became fully visual three decades ago! The value of Markdown is that it defines a limited set of semantic blocks and text styles so that the markup and css needed to render the content is finite and predictable upfront. It seems to me this advantage could be achieved with an editor designed specifically with this idea in mind. The editor could be fully visual, but it would respect a pre-defined set of rules regarding content semantics. The editor could output an XML or JSON tree of content with semantic labels that you could then run through a markup generator. That way you have full control over the markup. Once you have that you no longer need to limit yourself to what markdown offers. Maybe you want to give authors the ability to create "warning" and "tip!" blocks when writing help manuals for example. If you define those blocks then the editor would allow the author to insert them.

rachelandrew 11y ago
We already essentially do that sort of thing within Perch (see Blocks: http://grabaperch.com/blog/archive/introducing-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".
- teleclimber 11y ago
  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.
- zapt02 11y ago
  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 11y ago
    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.