I've created a screencast comparing the user experience for entering data via Markdown vs. TinyMCE WYSIWYG:
WYSIWYG vs. HTML Helper Screen Cast at Blip.tv
There is a prevalent assumption that WYSIWYG's are easier for end users. I argue the opposite in the screencast. I made it to help shops convince their clients that an HTML helper is the way to go. Seems like most shops just assume they have to give their clients a WYSIWYG. We know all the reasons developers don't like these tools. The screencast I did is making the argument on usability grounds.
WYSIWYG interfaces:
- Offer too many choices
- Present frustrating roadblocks (e.g. grayed out icons)
- Are not truly WYSIWYG (e.g. hyperlinks look like hyper links but aren't actually "hot")
Please add to this list. Or comment on the issue of the usability of WYSIWYGs.
A related issue is: why do clients think that they MUST have a WYSIWYG and why aren't developers making more efforts to convince clients otherwise?
I started a similar conversation which has gotten a bunch of responses on the consulting list serve.
Shai
Comments
Make it a fair comparison
The number of buttons in most WYSIWYG editors is configurable. See e.g. http://www.fckeditor.net/demo/toolbar?toolbar=Basic
If you want to make a fair comparison between WYSIWYG and Markdown at least reduce the number of buttons to the formatting Markdown is capable of.
Alternatively you could show us how to create a 5-by-5 table using your HTML Helper ;-)
.
WYSIWYG editors:
1) Are highly configurable.
2) Often don't produce the expected result.
3) Are--in terms of the visual interface--what users expect to see.
4) Actually do have live links, you just have to hold CTRL to use them; and you can click the HTML button to see the true markup if you need it.
HTML Markup Helpers:
1) Are simple, and intended to be that way.
2) Don't look anything like the result you want.
3) Are confusing for someone who has no idea what the commands are supposed to be.
4) Require that you start with knowledge about how to use them.
Sorry, but did you acctually
Sorry, but did you acctually test users with both solutions?
I see a lot of * I think * , but the comparison is completely off. Saying that text markup(HTML ish) is better then a WYSIWYG from a usability standpoint?, to me sounds very wrong. If you look around you, any usable application (from the google guys to wordpress) uses WYSIWYG editors, from your standpoint they are wrong? The whole concept of a WYSIWYG editor is to be more usable then a text solution.
That the solution you used, has major issues usability wise, doesn't mean the concept of a WYSIWYG editor is wrong.
Explaining where I'm comin' from
Bojhan,
I'm a bit of a contrarian. I like challenging conventional wisdoms (accepted "truths" that maybe haven't been investigated in a while -- or ever). I don't think I'm all right and everybody else is wrong. However, my experience has been that when people challenge a conventional wisdom it gets everybody thinking. And thinking is a good thing.
My argument is admittedly not based on any formal research.
"Usability" exists in a context.
Lets look at Gmail. Google has a gazillion dollars to spend on an ap that does one thing - email. And even then their WYSIWYG still has problems. But it is far, far better than TinyMCE or FCKeditor. It is, indeed, usable. And I don't begrudge them that usability. I'm not saying gmail should switch to Markdown.
Drupal, on the other hand, is a "Lego" set, powered to build almost anything. I'm impressed with how often I install a module and it works out of the box. It says a lot about the internal APIs the Drupal community has developed and the willingness of module developers to follow those APIs. It's almost miraculous. In the Drupal context, I believe that WYSIWYG's simply bring in too many moving parts to a system that already has many moving parts. I believe that the TinyMCE install is the same size as Drupal core.
With Drupal 7 we'll hopefully have a WYSIWYG in core which will solve a lot of these problems. The fact Dries and Acquia are moving on (and paying for) the development to get a WYSIWYG in core I think is testimony to the failure of the current solutions.
IceCreamYou has it right. There are pros and cons to each solution. I wanted to point out that being comfortable with the look to an interface isn't the only test of usability.
Shai
Shai Gluskin
Content2zero
Lego vs Usability
I understand you want to challenge conventional wisdom, sadly usability is still very leaning towards conventions - I believe that this is changing, but especially on the web certain interactions within applications are based on experiences within others. Of course Google is a different context, but the interaction is not much different.
I wasn't pointing to formal research, informal will do just fine - as long you take into consideration that your clients might not be our clients and might not be the community, its hard to apply this - since common wisdom says to go out of own experience. The idea is to step out of the what we think box and step into the what works box, by testing.
Of course Drupal is lego, but the outside doesn't have to be lego (can it be playmobil? I love playmobil). The idea within the community currently is that because Drupal is so complex, the interface will be complex as well - this isn't true.
I actually did 2 informal studies on WYSIWYG editors in an application we use in house, this wasn't a study of markup vs wysiwyg but to find out what the best setup of the WYSIWYG editor was. Where we saw great increase in efficiency for first time users and intermediates by good visual design of the actions and limiting the amount of functionality - most of the data was really specific so not applicable in this case, but I think that most WYSIWYG editors are simply poorly designed and that working and testing on little details in the WYSIWYG interface will get us much further then technology wise a "perfect" WYSIWYG editor.
Technology wise, WYSIWYG might be horrible but usability wise its not - that's all I wanted to point out.
Config
Interesting but clearly biased.
As much as I love markdown, i wouldn't recommend it for most "end users". Even though it's a simple syntax, you have to memorize it. Users who don't edit content often will forget things, especially how to create a link, "Was it [ or ( for the link text? Is the URL before or after?".
People want RTEs, and you won't convince them because for them using an interface they already know is priceless.
Grayed icons are standard in many apps, including the word processors RTEs try to mimic. I'd even say an icon that is not grayed out when you can't use it is a fatal flaw. People can be lazy when they have to learn something, but they're not dumb.
That said, my oldest client is 75 and has no problem using Markdown... Go figure.
What I usually give users -unless they need tables- is this small set of buttons:
Not too bloated I'd say.
A great feature in TinyMCE is the Styles menu. Users can select a bit of text, choose a style and boom, the text is automagically formatted. The selected quote here has the style "Extrait". Give them a few carefully designed styles and they don't need to deal with font faces, sizes and colors (which usually results in a mess in RTEs), and the design remains consistent across the whole site. As far as I know, if you need a class on an element in Markdown you have to write it in html.
TinyMCE is still a pain to configure though.
Regarding links both RTEs and Markdown have a problem: when you want to create an internal link, you have to know the node ID before you create the link. Here popups could help with a node list, or maybe an autocomplete field where you could type a part of a node title.
Anyway, I have to admit RTEs are often frustrating and users have a hard time getting the result they want. The best advice I can give theme is "Keep it very simple. Really. This is not InDesign, or even Word. Not even close."
+1
elv: great post. I too like to remove as many of the buttons/options as possible.
Does your limited tool set prevent problems from pasting?
Elv,
This is great. Thank you so much. I think I'll follow this example.
However, please clarify one thing. Your limited button set will not prevent ugly html getting inserted via a paste from Word or another application. Will it?
I find TinyMCE's "Word Paste" button more trouble than it is worth. What does it do?
I keep telling myself if I had thirty hours to really dig in deep to TinyMCE I could probably figure it out and make better recommendations to my clients and do far better configuring on the admin site. But I never seem to get those 30 hours.
One thing I like about plain text boxes is that none of that garbage comes with on a paste. Is there a way to configure TinyMCE so that pastes bring in plain text. Is there a way to make it so that only after the paste happens the environment becomes "rich."
I sometimes say to people, "When copying from Word, paste it first into Note Pad, then copy and paste it again into your Drupal node/add body field. People hate that extra step.
I'm all ears...
Shai Gluskin
Content2zero
Two buttons
There are two "Paste from Word" buttons, so you really have three possibilities:
just paste with Ctrl-V, and the formatting (and possibly crappy html) will be kept
copy from Word, then click the "Paste from Word" button with the small W icon. Then TinyMCE tries to convert to sane html, but some formatting will be lost. No great for users, because the result is somewhere between plain text and what they had in they Word doc.
copy from Word, then click the "Paste as Plain text" button and it does what it's supposed to do. This is basically the same as pasting in a text field without a wysiwyg editor, so it's propably what you are looking for.
Note: if you use IE these buttons simply insert the text in the content field. If you use another browser you'll get a popup with a field to paste your text, then have to submit.
I should really put all this in a blog post and/or a handbook page. But TinyMCE 3 is out, there are lots of changes and I didn't have time to experiment much with it. And my own site is still barely a few notes on a paper pad :)
The tips for the 2.x branch may still be useful though.
Thanks for the great instructions
Hadn't noticed the "paste as plain text button" before. That is really helpful. On the configuration screen that button is labeled "Paste text/word" which is a bit more ambiguous than the tool tip, which I think is much better, "Paste as plain text."
Shai Gluskin
Content2zero
"Paste from Word" can be made more powerful
TinyMCE provides additional options to the "Paste" plugin that allow the administrator to tune what gets kept and what gets cleaned out from a paste operation. While these options are not yet implemented in the TinyMCE module, I've made a start at doing so (see http://drupal.org/node/304623).
There is also an alternative plugin called Simplepaste that automatically cleans Word formatting, but I haven't been able to get it to work well within Drupal yet.
Perhaps we could agree on a
Perhaps we could agree on a set of buttons and turn this into a straightforward module. No configuration, except for the styles. And because only 10% or less of TinyMCE would be used perhaps we could prune or replace TinyMCE as well.
Wordpress WYSIWYG
I personally use Markdown for my both sites (blog & work) but I agree with WYSIWYG.
The best WYSIWYG I ever used in CMS is Wordpress' WYSIWYG. TinyMCE or FCKEditor make me feel 'hackish' compared to Wordpress. You should try it for your experiment.
TinyPress?
Last time I had a look, the default wysiwyg editor in WordPress was TinyMCE. But it has a nicer and stripped down interface by default. Maybe we need better default settings in Drupal's TinyMCE module?
Edit: http://codex.wordpress.org/TinyMCE
Strip down
Surely we need to strip down the interface. Not just the number of buttons, but the number of options in general. I can understand the TinyMCE developers are proud of having built e.g. a language direction option for images, but I fail to see why this option has to be provided to every user by default.
On an unrelated note: I followed your link and tried to find out on the Wordpress site what their version of TinyMCE looks like. This appeared to be quite hard. Only by typing "demo" in the search box I encountered a page with screenshots.
Getting curious I compared drupal.org. It has both a screenshots and a demo link prominently on the front page. Much better. However, screenshots lead - after 3 clicks - to what seems to be a random set of admin pages, and demo leads to a confusing page at opensourcecms.com. This can be improved.
gaele - I opened an issue to
gaele - I opened an issue to remove the demo link a while back, but not much happened with it - re-opened here: http://drupal.org/node/225173
I'd only implement a markup
I'd only implement a markup filter (and it has to be (Textile)[http://drupal.org/project/textile]) for sites that require a certain level of formality and quality control, where the contributors were prepared to put a small amount of effort into memorizing the markup. But for everything else an editor is usually more appropriate.
The main benefits of an editor in my opinion:
* Being able to fiddle with the layout of elements
* Uploading, inserting and managing pictures
* Inserting and removing links (the markup alternative is always difficult to memorize)
* Inserting a teaser break (even if the icon makes little sense)
* Not having to study the code to find out what's going on (markup is invisible)
* Adding extra attributes to elements such as classes (list to choose from), target="_blank", width/padding/etc
If I wanted to convince someone why they might prefer a markup language over an editor I wouldn't show them that screencast, it's clearly biased and the only impression I get is that you don't like TinyMCE. In the last two weeks I've trained seven people how to use TinyMCE in their Drupal sites and none of them had a problem with the points you brought up in the screencast.
Some of the most difficult things to teach clients include:
* How to add padding between text and an image
* Why they should use the paste from word feature. It's because when you paste the Word text into the popup window it retains most of the formatting, such as bold, italic, headings, etc, while conveniently stripping out the non-HTML tags. It can also be useful when copying content from your old website.
* Explaining what the hell description (alt attributes) and title text are, and why they're important in different circumstances
* How to wrap text around an image effectively
* How to use IMCE
How is a simplified markup language going to make any of that less challenging?
"A related issue is: why do clients think that they MUST have a WYSIWYG and why aren't developers making more efforts to convince clients otherwise?"
Btw, does anyone else hate the way the red 'loading' box flashes when writing a post here (for auto-preview)? It's like someone's blowing into my ear every few seconds.
Btw, does anyone else hate
Yes.
Perhaps the red box:
+1
Right now it's just disturbing, it look like an alert message. It should be positioned above the preview, possibly on the right of or below the "Comment Preview" title.
While we are griping about g.d.o -- I've got a captha issue
Every single time I post to g.d.o. I get the message,
What kind of algorithm is it using? Do my posts really seem like spam :)? I'd much prefer simply having the captcha in the form the first time I fill it out if I'm never going to pass its algorithm anyway.
Shai
Shai Gluskin
Content2zero
Mollom
http://www.mollom.com/
I rarely get the captcha on here. Maybe it's your IP?
Oooooh, the irony! Just got hit with it. LOL Mollom, dear, don't you want me defending you?
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
The loading box just
The loading box just shouldn't be. I can't think of any good reason to have it.
Sync
In some way it should be clear whether the preview box is in sync with the input box. The loading box is one way. I'm not sure if it's the best way.
On a bunch of your points...
+1 on your criticism of the red flashing thing for auto-preview on g.d.o. "Blowing in my ear." Perfect description!
Since the Drupal 5 version, IMCE works in plain text boxes. It can handle images and files. It works fine when combined with an HTML helper like MarkSmarty. In short, all the IMCE goodness can be had independent of an RTE.
Doesn't TinyMCE's native way of doing that use deprecated html image attributes? I create a custom style that uses CSS, so there is certainly a way around that in TinyMCE. The image wrapping is the most compelling reason to me to use TinyMCE. On the sites where I don't use an RTF I have people add a class I've created,
class="imageleft"to the code IMCE has created. Anybody know how it might be possible to get IMCE to add a class definition automatically?Re: paste from Word. My (albeit limited) experience is that it preserves those nasty MS styles which can wreak havoc on the page, especially line spacing and wrapping.
Re: "the markup alternative to links is difficult to memorize." Agreed. I put very simplified instructions for bold, italic, and hyperlink on every node/add form.
Re: "Explaining what the hell description (alt attributes) and title text are, and why they're important in different circumstances." For alt I give them the example of a blind person's screen reader. That is both very motivating to folks and gives them a clear, simple example of its application.
Overall, I'm taking in the excellent responses here and thinking about how to incorporate an RTE in a way that is familiar to the user, the developer, and keeps code clean.
Shai Gluskin
Content2zero
WYSIWYG is added on to Drupal, but not "integrated"
Shai
Indeed, you are right.
In a nutshell, WYSIWG, at least with both FCKEditor and TinyMCE , are successfully added on to Drupal, but are not "integrated". It takes a bit of work and tweaking to really "integrate" them
http://moinmo.in/ for example has done a great job of actually integrating Fckeditor into their application
In my opinion, FCK is the nicest rich text to use with Drupal, but many of the controls do not work without some tweaking and adjustment (or allowing style tags, and other questionabe stuff)
Sam Rose
Social Synergy
Open Source Ecology
P2P Foundation
Sam Rose
Hollymead Capital Partners
P2P Foundation
Social Media Classroom
I ud
I use TinyMCE for quite a while now and I have to admit I've ran in too many problems with it. The options are endless and I've not seen an RTE / WYSIWYG editor who matches TinyMCE, even FCK doesn't in my opinion.
I've written my own module to easily implement TinyMCE, in combination with it's MCImagemanager and MCFilemanager, instead of using the tinymce module Drupal offers. The module I've written made it possible to easily customize the toolbars using drag and drop. My module also made it possible to create roles for the editor. Administrators can create roles in which they can specify where to display the selector, depending on which pages and on which user roles. The editor is appended to DOM elements using an jQuery selector, set in the role created. This way the editor could be applied to more than one element on single page.
Also the MCImagemanager as well as the MCFilemanager have their own settings page. This way there is no need for editing the config.php files anymore.
The module works really great ,but still the real pain is TinyMCE who was such a long learning-curve and messes up your HTML almost always. I would prefer building our own Drupal RTE. (not WYSIWYG). I've got a lot of ideas about it, and will follow this discussion.
add_rte_profile.jpg