Posted on May 10, 2007 | Tags:
Earlier this week I spent an afternoon setting up and configuring WYSIWYG editing for a client’s website. Although at Chapter Three we are big fans of HTML Literacy, we realize that many users would feel more comfortable in a WYSIWYG environment. We did a little brainstorming and came up with some basic recommendations to make TinyMCE work better.
1.) Keep the Interface Simple - TinyMCE out of the box has all of its bells and whistles displayed which is in some ways cool - TinyMCE can do a lot. However, much like the selection at Old Country Buffet, sometimes too many options can be confusing and hard to narrow down. There is a temptation to leave options there that “may be useful”. Instead, we first started by disabling all of the options and then selectively enabling only the options we really needed. This ended up being just the bold, italics, underline, font size, and ordered list buttons. Keep it simple or you will end up showing your users something monstrous like:
Bad:
Good:
2.) Resizing Good, Path Bad - TinyMCE allows for textareas to be resizable and this is a wonderful feature. It gives users more space to work and is far less annoying than having to compose a page long post by scrolling through a four line tall textarea. The problem is that in order to enable this feature in TinyMCE you also need to turn on the “Path Display” option. This feature allows users to see their current depth and path in the HTML code and can be useful in some cases - including building HTML literacy, but in most cases its both cluttering and confusing. To remove it and keep the resizing option, we simply enabled them both and then used CSS to hide the information:
.mceStatusbarPathText { visibility: hidden; }
3.) HTML Literacy is Still a Good Thing - Even though the user is working in a WYSIWYG environment, allowing the user the ability to be exposed to and maybe even edit the HTML code can be a really good thing. TinyMCE allows for the creation of a “HTML” button that creates (in a separate window) a rendering of the textareas HTML content and allows the user to edit the code. Now, it is best to keep the interface simple, but helping to educate users about HTML can be a really good step to improved HTML literacy.
4.) Only Use TinyMCE When You Have To - The easiest way to simplify the way TinyMCE is used on your site is to only use it in cases where you really need WYSIWYG editing capabilities. This is, unfortunately, a little tricky to do in Drupal since the Drupal implementation of TinyMCE only allows the display of WYSIWYG editing on a per page basis instead of a per field basis. This is typically not a problem since most pages just have one textarea, but if you have a page (say the editing of a particular node) with multiple textareas, but only want TinyMCE on one or two of them, its sort of tricky how to do it.
One possible solution - that we ended up using - is to use a theme override for the TinyMCE theme to enable or disable textareas based on name. This solution works in tandem with the built in display controls and simply adds the finer grain control needed. In this example, we have only enabled TinyMCE to show on node/* pages but have four different textfields that we do not want TinyMCE to show on. To accomplish this we use the following theme override:
<?php
function themename_tinymce_theme($init, $textarea_name, $theme_name, $is_running) {
// Determine what Textarea we are working with
switch($textarea) {
case "field-quotes-0-value":
case "field-shortcomments-0-value":
case "field-blurbs-0-value":
case "field-shoutouts-0-value":
// If it is a textarea we do not want TinyMCE to show, remove the $init variable
unset($init);
break;
}
// Return the $init variable
return $init;
}
?>
