on the (lack of) usability of rich text editors in Drupal

I’ve been using Drupal to power websites for several years now, since 4.6 was the latest and greatest. One of the constant, ongoing, relentless complaints from our users has been that Drupal is (or seems) too complicated. It seems hard to use. It takes some care and feeding to initially set up a site. For example, when installing Drupal and creating a site, there is no option to have a rich text WYSIWYG editor, out of the box. Sure, übergeeks would rather gnaw off their paws than use a rich text editor, but Real Live Humans™ need them. They need to be able to edit text visually, and to upload and embed media, without having to follow recipes or read through pages of instructions.

I’m in the process of setting up a new website for a prof, so she can use it with her 200 students as a collaboration hub. Setting up the site (Drupal 6) took maybe 5 minutes. Installing extra modules like Organic Groups and Views? Maybe another 5 minutes. The site is working pretty much perfectly, about 10 minutes after starting to set it up. Yay, Drupal.

Except, I can’t get a rich text editor working the way the students will need it. They need to be able to just start typing, and to upload, resize, and embed images. I’ve got the wysiwyg-api module installed (and why in hell does it not INCLUDE an actual rich text editor? seriously.) and have been farting around with various image-assist and image-api and image-embed and image-etc… modules to get an “embed image” function working. And I can kinda/sorta get it working, as long as I can expect students to be geeks. But they’re not. We need a nice, simple, clear “upload image” button as part of the rich text editor. And that’s just plain not working.

Interestingly, while writing this blog post, the WordPress “Upload/Insert” media bar above the text area is exactly what I need in Drupal. I can’t just use WordPress, because I need to use the collaboration features offered by Organic Groups – and that’s just not possible with WordPress.

So, although I got the skeleton of the website up and running in about 10 minutes, I’ve been farting around for 3 hours now, trying to get a fracking “upload/insert media” function working at the level that will be required by the students. I’ve almost got it working, but the result is something only a geek would really use. And a geek wouldn’t be using the WYSIWYG editor in the first place.

Why in hell is a fully functioning rich text editor not included with Drupal Core? And why in hell is it not as fully featured as the WordPress one, with media uploading and embedding? I’d be willing to bet that the addition of a functional WYSIWYG editor would go a LONG way toward improving the perception of usability of Drupal. Heck, WordPress is GPL – just yank the one they use…

17 thoughts on “on the (lack of) usability of rich text editors in Drupal”

  1. I, too, have been using Drupal for a while now and feel your pain. The WYSIWYG API should help a little (so, for example, not ALL textareas use TinyMCE or FCKEditor or whatever), but still, the lack of ability to easily upload and manage images, or any media for that matter, is frustrating to say the least. There is some work currently being done for Drupal 7 to improve file and media handling and I know that doesn’t help your situation now, but at least the community is aware of it and actively working on it.

    I haven’t used wordpress in a while but just signed on to a hosted account I had to check it out. It’s interesting, because the WordPress WYSIWYG editor is still not even WYSIWYG. The buttons and uploaders simply use javascript to insert HTML code into the textarea. Not the same approach, but I’d agree with you that it’s an approach that works better. If I recall correctly, the WordPress editor is based on Alex King’s quicktags, for which there is a Drupal 5(!!!) module: http://drupal.org/project/quicktags

    Maybe it’s time to resurrect that module and update it for Drupal 6/7? Sorry for the lengthy comment, but it’s a sore spot in my otherwise wonderful Drupal experience!

  3. I was under the impression WordPress used TinyMCE? It’s the image handling that is the worst problem, and until we have solid image handling in core I can’t see us getting decent image handling in a wysiwyg editor 🙁

    Yesterday I was contemplating an install profile with wysiwyg-api, tinymce and htmlawed all configured with a decent input format. It’s such a pain doing them all for every site.

  5. You may want to check out the usability group on groups.drupal.org. There’s a lot of activity going on over there to try and overcome many of these issues in Drupal 7. Again, I know that doesn’t help with your frustration now, but it is being looked at.

    Get involved by joining the group and commenting on what’s going on over there. There’s lots of good discussion, and quite a few mentions of the “WordPress way of doing things!”

  6. Another guy having issues with the lack of a decent WYSIWYG editor in WP.

    I’m with you on this one, just yank the code used for WordPress, hack it a bit and then connect it to the WYSIWYG API to get something decent out of it. Then make some code to make the Image Assist module work with it, as it’s the closest thing to the way WP does it.

    I’ve got a site I’ve been wanting to open to users for registration, but until this is resolved, I don’t think I’ll be able to get non-geeks to actually do so.

    The QuickTags module mentioned by Steve looks like a good interim solution, so I’ll try that.

    I do think they need to focus on usability on Drupal 7 quite a bit more than they did on 6. People will overlook missing features or changes in Core (for module creators/maintainers) if it’s easier to setup and manage an installation.

  7. Guess the 12-hour odyssey to get some liquidation money out of my boss is showing:

    “Another guy having issues with the lack of a decent WYSIWYG editor in WP.”

    Meant Drupal, not WP 😛

  8. I’ve actually spend a few hours the last couple nights trying to hack something together to get this working. Just to be clear, we want something that looks like this:

    http://www.stevekarsch.com/sites/stevekarsch.com/files/wordpress-editor.jpg

    in Drupal, right? The editor seems to be the (somewhat) easy part…the nice UI on the image uploading/scaling will be a little more difficult and I want to make sure I’m not duplicating the efforts of the recent media sprints. Once I have something that’s even a little bit ready for prime time I’ll add a module to drupal.org.

  9. The WYSIWYG editor itself is rather trivial – any of them would work well enough for just entering text and making it purty. It’s the integration with media management (write a blog post, upload an image, insert image into blog post) without needing to do strange stuff like File Attachments (and copying the URL of the uploaded file, and pasting URL into the image tag editor, etc…) without being a geek. It works, but not cleanly. Try explaining the process to someone who is overwhelmed just using a website in the first place.

    Something like the WordPress Upload/Insert bar shown in Steve’s screenshot would go a LONG way toward making this more usable – assuming it talked properly to whatever default WYSIWYG editor is used (because there REALLY needs to be a default WYSIWYG editor – taking the “we don’t ship one so you can pick the one you like best” stance is a copout, since only the most über of übergeeks would give a crap about which editor is used, and they won’t be using the WYSIWYG editor anyway… it just needs to be there, and it just needs to work. end rant.)

  10. I don’t think rich-text editor is synonymous with WYSIWYG editor. WordPress’ default editor does a decent job of managing and marking up content, and exposes that power via the row of buttons a top of the editing area. That’s not WYSIWYG editing. It works when you’re in code mode, too. To me, that’s a rich-text editor; rich for managing more than just plain text and making that accessible to users.

    Drupal’s rich-text abilities only goes as far as input formats and filters. WYSIWYG editors then get slapped on top with all the appearance, but none of the power, of a something that truly cares beyond a blob of text. “Lipstick on a pig,” as the saying goes.

  11. I was tweeting about this a while back when I was digging into a dev site. I really like Drupal and think that it’s awesomeness will be revealed to all when they “make it so easy your grandma could write a post with embedded media”. WP still leads the charge in that area IMO.

  12. I think I’m missing something. I did a short (under 2 minute) screen capture of uploading a photo to a drupal website using FCK and ICME. ( http://eduyukon.net/demo/Drupal%20Demo.htm ) I showed this to a couple of my colleagues to make sure it was not “geeky”. They don’t think so. If this is the kind of behavior you’re looking for, the tutorials mentioned in my earlier comment will help.

  13. Ah. FCK and IMCE was a combo I hadn’t tried. I’ll check that out. The screencast is a definite improvement, but still isn’t something I’d want to roll out to a large number of students without being able to provide intense technical support. “Browse server” would throw many off. Guaranteed. “The photo’s not ON the server. Why would I browse the server?” (yeah, we can tell them to do it anyway…) And the debug log in the lower left panel of the IMCE window will confuse or scare some. It works, but it’s hardly clean or streamlined. It works despite the clumsy interface.

    But the point still remains that site maintainers need to find a formula, and download and configure modules to get it working in a non-geeky way.

  14. Agreed. That was my original complaint. It’s not great. I’m hoping they’ll clean it up and do much better. Just wanted to point out it’s not quite as bad as it would appear at first glance.

  15. Thanks Grant! I’m also working on a post that outlines how to do it with Image + WYSIWYG API + TinyMCE. I guess the point is, it CAN be done, it’s just not very clear how!

  16. We use XStandard internally … it is proprietary and cost prohibitive to deploy more broadly, but it really works well (AND GENERATES CLEAN XHTML!). You should take a peak sometime. Wish there was a quality OSS alternative.

Comments are closed.