Paste: it’s what’s for dinner (wysiwyg and pasted content)

Original image here:http://www.gamespot.com/users/BenderUnit22/view_image?id=OtB

With the education-focused sites I’m building these days, it has been very difficult to deliver a site that does not provide some sort of WYSIWYG editor for the end user. Users want to be able to use the same sort of tools they have in Microsoft Word, and if they can’t, they aren’t going to be comfortable in the new web site.  

But Rich Text Editors create their own set of problems. These days, you’re problably using the excellent WYSIWYG editor module, and one of the available editors.  I’ve made the most use of CK editor and Tiny MCE over the years, but there are others.  As you work with them, you’ll find some that you favor, but configuration can be a real chore if you’re not careful. 

To begin with, the WYSIWYG module makes no direct connection to the Input Formats module to make sure that your Filtered HTML input format will allow the code types you have enabled in your editor window.  This can create a big problem with your customers and users — they’re going to be making changes in their editor window that they will not see in the finished page.  

The obvious easy solution is to switch the default input format to “Full HTML” — that solves the problem quickly, but it opens up your site to a variety of HTML that might really gunk up the display of your pages. There are a handful of input format Modules out there, and you may find one that will support your use case, but there’s no clear winner that I’ve found to date.  And I imagine that it would be difficult to write a module that will connect WYSIWYG to Input Formats to ensure that the filtered HTML format (or another limited format created by WYSIWYG) contains all of the necessary permitted html tags based on the WYSIWYG module’s configuration — since the editors do things their own ways, that would mean a pretty serious undertaking.  

But, even if you just take the easy way out and set the default input format to “Full HTML”, you’re still going to face a new problem — Microsoft Word. Word is ubiquitous these days, and it uses an arcane melange of code to format it’s content.  A lot of that formatting will translate in a web environment, but it isn’t consistent, and it’s unpredictable.  

There are a couple of solutions, but most require that you put in a little time and effort training your users to pick up some new behaviors — which is usually a bigger problem that I think it will be. 

  • Filter the Content through Notepad.  Notepad is the free text editor that comes with windows, and it’s simple enough that all it reads and stores is the text.  It’s usually a simple matter to paste the content from Word into notepad, then copy the simple version of the text out of notepad into your web site’s editor window. (other text editors will work, but they need to be very simple — Wordpad retains too much formatting.  Textmate, is my favorite on a Mac)  
  • Disable the Editor. If you have configured your permissions and editor settings so that the user has the option to turn off the editor window, you can encourage them to turn off the editor before pasting the text in from word.  Then, turn it back on and use the editor tools to create your formatting. 
  • Paste from Word buttons.  Many, if not all of the editors available include a “paste from word” button.  In most cases, users can click on this button which pops up a window in which they can paste their copy.  

The trick with all of those solutions is they’re all new behaviors for your customers. And, unlike you, dear reader, these users don’t live and breathe web site content tools.  They’re on there once in a while.  They don’t use the tools often enough for these never behaviors to become second nature for them, so in a couple of months they’re going to bump up against the same problem.

Which brings me back to the idea of using WYSIWYG editors in the first place. Use them sparingly. You might want to consider not making the editor the default, and force users to turn it on if they really need it. Only make it available for specific content types, specific fields, for specific user roles.  Most users don’t need those tools, and you can make their lives a lot simpler without them.  


Leave a Reply

Your email address will not be published. Required fields are marked *