I’ve been a fan of Markdown for quite some time, but never took the jump to fully implementing it on any of my sites. I always had this nagging issue of ‘what if I want to switch back?’ and I simply continued writing my posts in TextMate and logging into WordPress for the 30 seconds it takes to copy and paste my article and hit the Publish button.

Enter Markdown on Save. This thing is perfect. It’ll give you a meta box with a checkbox dictating whether or not the current post is formatted in Markdown, but the better part here is that the Markdown version of your post is stored separately from the HTML version. Why didn’t I think of that?!

If at some point down the line you find yourself hating all things Markdown, you can deactivate the plugin, and your HTML-ified content is as though you wrote it that way. Big thanks to Mark Jaquith for this one.

Advertise here with BSA

Destroying aesthetics with each update

Personally, I think content management systems are an extremely effective way to increase functionality and organization of websites large and small. They come in extremely handy when providing a website as a product for a client, allowing updates to be made at any time without the assistance of the site developer. While all intentions can be positive, sometimes a gorgeous product can be all but destroyed upon delivery when it comes to creating or modifying site content. With each update, a well thought out design can be further altered from original intention, reflecting poorly on the site aesthetics. There are a number of ways for clients to make updates in various CMSs, but which is best?

WYSIWYG

First and foremost is WYSIWYG content editing. This option, to me, seems most appropriate for people who have no experience with (X)HTML and are looking for the easiest way to make updates to their content. It is probably the most attractive option for clients as it bridges a gap between the copy they’re editing on the back end and the copy displayed on the front end.

I’ve got a bit of a personal gripe with WYSIWYG editing, not only when it comes to any particular CMS, but in general as well (when it comes to the Web). While there are benefits to this form of editing, they all lay with the particular user actually making the edits to the content.

Most of the time, the markup which results from WYSIWYG editing is far from semantic, and often gives the editor far too much control over how various elements appear. All of a sudden, copy can be filled with long strings of bold, underlined, and italicized text simply because the icons are there to click. Awkward font colors and sizes are suddenly used throughout the website, and greatly degrade the overall look and feel the original design worked to establish. What is the best way to handle something like this?

Markdown & Textile

Plain text and readable editing systems have become a very popular way to give the ability to edit content while attempting to retain a semantic and valid document structure. While the resulting interaction is (more or less) easy to read and decipher, it still requires a bit of a learning curve to undertake. There is a certain breed of client that would be willing to put forth the effort to learn a tool such as Markdown or Textile in order to manage the content of their website. To be completely honest, I would have to say the majority of clients I’ve directly worked with would greatly prefer a WYSIWYG editor. As a developer, however, I’d definitely prefer a plain text editing system simply because of the comfort in knowing the resulting markup will be valid and (mostly) conform to the styles established in the site design.

BBCode

Another system implemented in some of the wide range of CMSs is that of BBCode, a markup language originally established for use in forums. BBCode shares a bit of raw (X)HTML and Markdown/Textile in that plain language is used, but proper tags must be maintained in order to obtain your intended results. While this form of editing has more-or-less stuck to forum installations, it’s another method to consider.

WYSIWYM

There are many ways to implement a system of editing in a CMS, each with their pros and cons. By far, the most attractive solution I’ve come across to date is WYSIWYM editing. The idea is a healthy blend between WYSIWYG to help make ‘the sale’ to the client, while including the importance of each element used. Styles can be directly applied in order to assist the editor visualize how published copy will appear, but proper attention is also given toward the markup involved.

At first glance, this system seems to seek the happy medium between client and developer approval. While the idea is fairly young (to me at least), and the flagship editor, WYMeditor is still in it’s infancy, I think this direction could bring some extremely positive results.

Conclusion

Content management systems try to cut the middle man out of site maintenance for site owners, but is it acceptable to completely stray from the way things work? Is hiding the markup that makes the Web work the right thing to do? Something about that doesn’t sit well with me completely. Playing devil’s advocate, does HTML belong only in the hands of developers? I think this is a bit of a gray area, but I’d love to hear what many of you think.

All in all my personal favorite of this bunch is WYSIWYM editing. Having the benefits of a visual depiction as well as maintaining semantic value seem like the ideal situation to me. The trouble we face is the fact that our clients can not be expected to understand (or care about) the semantic Web, accessibility, or the intention behind our designs. Which system of editing does your CMS of choice employ? Have you had past projects lose aesthetic appeal as a result of giving editors too much freedom with editing? What do you feel is the most effective system of editing, both for the client as well as the semantic, accessible Web?

Advertise here with BSA