Status update: WYSIWYG support in Drupal core

[Daniel F. Kudwien]

<Digital7> tha_sun: on the previous subject..so you know, wysiwyg is less customizable than straight up fck[editor.]module
<Digital7> tha_sun: it's missing the ability to re-skin the buttons
<Digital7> tha_sun: and it won't drop down a 2nd or 3rd bar for a full set of menu bar buttons
<tha_sun> If you can code, you know how to alter the default skin.
<Digital7> tha_sun: i mean by standard configuration
<tha_sun> sure
<tha_sun> We've got a lot to do in the area of wysiwyg api...
<Digital7> tha_sun: no complaints though, that is definitely a better module once it is a bit more mature
<tha_sun> OTOH, unlike fckeditor.module, wysiwyg api requires no hacks in other modules, manual config file changes, etc.
<Digital7> tha_sun: that's a plus...fckeditor.module burned several hours of my time
<Digital7> tha_sun: initially
...
<Digital7> tha_sun: what's keeping you from getting that module standardized in drupal?
<tha_sun> Digital7: I guess you mean in core?
<Digital7> tha_sun: yes--if that's the proper term for a module included with the standard installation
<tha_sun> Digital7: There are many reasons.
<tha_sun> Digital7: Starting with http://drupal.org/project/libraries
<tha_sun> Digital7: A few others...
<tha_sun> But ultimately ending in: countless support and feature requests, which Drupal core most likely can't handle.
<Digital7> tha_sun: seems like it'd be a top priority for the project..given how significantly it improves the usability
<tha_sun> We have yet to find a solution for this issue.
<tha_sun> You know.
<tha_sun> I'm an evil maintainer.
<tha_sun> You get a won't fix before you submit an issue.
<tha_sun> Drupal core, though, depends on many volunteers to do this job.
<tha_sun> And, many of them, don't know the innards of the system.
<Digital7> i still see it happening whether it be sooner or later
<tha_sun> So, insane feature/support requests live too long, although they won't ever fix.
<tha_sun> If we add wysiwyg to that list, we will double or even triple the size of all open core issues.
<tha_sun> It will happen. We just have to find out _how_.

[Damien Tournoud]

On Sat, May 23, 2009 at 8:41 AM, Daniel F. Kudwien <news@...> wrote:

[...] Long IRC message from Daniel

Erm. WYSIWYG support not being in Drupal core because the core queue could not handle the support requests? That seems a little bit far fetched.

My own explanation is more simple:

- We haven't found yet a non-crappy jQuery WYSIWYG editor licensed under the GPL (and a even just a non-crappy WYSIWYG editor, for that matter)
- It is doubtful that a WYSIWYG editor improve usability
- On the other hand it is certain that a (non correctly configured) WYSIWYG editor can decrease the efficiency, by (1) encouraging people to use inadequate markup, and (2) allowing them to copy/paste from some brain-dead desktop applications

In a nutshell, the WYSIWYG editors, as we currently know them, doesn't fit every need, so there is no reason to bother to have one in core.

I have said that a few times already, but the answer to questions like "everyone needs a WYSIWYG editor, Drupal should support that out of the box" (feel free to replace "WYSIWYG editor" by "a better forum", "trackback support" or "a pony stable") is *not* "that should be in core", but "people should step up to create and maintain a Drupal distribution that fits these particular needs". Because, no, not everyone needs that, and core is already sufficiently large so that a few areas are already poorly maintained.

Damien

[Arancaytar Ilyaran]

Damien Tournoud wrote:
> - It is doubtful that a WYSIWYG editor improve usability

Hear, hear.

BBCode and Markdown isn't hard to get into, and it's used on all forums
I've ever seen. On the few forums that offer a choice between BBcode and
WYSIWYG, people complain that WYSIWYG is clumsy to work with, puts extra
line-breaks and paragraphs where you don't want them, doesn't usually
reflect how your post will actually look after submission, and slows
down the browser.

I feel that the very concept of WYSIWYG editors does great damage to
user experience - ultimately, learning to emphasize like *this* or
/this/ or even [i]this[/i] will be less frustrating than clicking
buttons that don't quite do what you want. The only "familiar
experience" it offers is similarity with poorly written word processors
that these same users are usually cursing all day. Madness! :(

(Sorry for the rant.)

--
Aran

[KOBA | Hans Rossel-2]

I agree with the fact that developers don't need a WYSIWYG editor. Writing code is easy and html is easiest of all. So its logical most developers are against WYSIWYG  editors. They are not needed for them and above that pollute the code.

But even if you write fluiently html, adding a big piece of content with headers, lists, tables is really a lot more work without a WYSIWYG editor. Certainly for people that are not used to write code. For them one of the advantages of using a CMS is that you don't have to learn html to add content.

I feel when there will be a discussion among developers whether or not to have a WYSIWYG editor, there will be of course consensus that there should not be one as its not good for the code. But developers are not the ones that add the content to a site, ask the people that add the content what they prefer.

Hans

2009/5/23 Arancaytar Ilyaran <arancaytar.ilyaran@...>

I feel that the very concept of WYSIWYG editors does great damage to
user experience - ultimately, learning to emphasize like *this* or
/this/ or even [i]this[/i] will be less frustrating than clicking
buttons that don't quite do what you want. 

[Dave Myburgh]

But even if you write fluiently html, adding a big piece of content with headers, lists, tables is really a lot more work without a WYSIWYG editor. 

Exactly. I find the same thing, and I like using BUEditor for this kind of thing. In fact, I try and push my clients to use BUEditor instead of FCK or TinyMCE. This avoids the problems associated with people copying and pasting from Word. Anyway, most people don't need all those icons in other editors, all they really need is the basic ones in the default BUEditor install. Plus, its easy to add new icons and functions if you want them.

Having something like this editor in core might be a better option, although I am fine with keeping it as a contrib module.

 

Dave

[Stefan Nagtegaal-8]

http://markitup.jaysalvat.com/home/

The ultimate jQuery WYSIWYG-editor, easily configurable and usable  
with different input formats. NO doubt that *if* we want an WYSIWYG-
editor in core at all, that it should be this one.

Kind regards,


Stefan Nagtegaal

[Andrew Berry-3]

On 23-May-09, at 2:41 AM, Daniel F. Kudwien wrote:

> <Digital7> tha_sun: seems like it'd be a top priority for the  
> project..given how significantly it improves the usability

Does anyone know of any papers studying the differences between  
various editor types, and if any of them can be shown to actually  
improve usability and user satisfaction? I did some searching, and I  
found:

http://www.jasoncornwell.net/projects/BloggerFinalReport.pdf

which is about a UI redesign of blogger.com; not much in there other  
than that users found editors to be problematic for image placement,  
and that the concept of previewing an edit didn't stick very well.

I also found this which may be of interest: http://doi.acm.org/10.1145/275269.275272

It's from 1998, but many of the issues it finds about HTML editors  
still seem relevant today. Complaints about poor code, overwriting  
custom changes, and general unreliability are mentioned, which all  
seem to apply to most of the JS editors today.

A comparison of WYSIWYG vs WYMIWYG would be very useful.

--Andrew

[Naheem Zaffar]

I don't think anyone would argue that having buttons on an textarea for commonly used actions is a problem in any way - I personally hate having th type out log tags like blockquote multiple times where spelling errors can cause problems.

As for actual wysiwyg, it depends on the implementation, and the thing here is if its not tightly coupled with the software, it shows.

A dual mode like in wordpress could be interesting, however I have visited fora (using invision power board I think) where there is some sort of hybrid mode where test was as in wysiwyg, but new additions could be made through adding more tags too.

[Steve Edwards-8]

http://drupal.org/node/208456

Andrew Berry wrote:

> On 23-May-09, at 2:41 AM, Daniel F. Kudwien wrote:
>
>> <Digital7>    tha_sun: seems like it'd be a top priority for the
>> project..given how significantly it improves the usability
>
> Does anyone know of any papers studying the differences between various
> editor types, and if any of them can be shown to actually improve
> usability and user satisfaction? I did some searching, and I found:
>
> http://www.jasoncornwell.net/projects/BloggerFinalReport.pdf
>
> which is about a UI redesign of blogger.com; not much in there other
> than that users found editors to be problematic for image placement, and
> that the concept of previewing an edit didn't stick very well.
>
> I also found this which may be of interest:
> http://doi.acm.org/10.1145/275269.275272
>
> It's from 1998, but many of the issues it finds about HTML editors still
> seem relevant today. Complaints about poor code, overwriting custom
> changes, and general unreliability are mentioned, which all seem to
> apply to most of the JS editors today.
>
> A comparison of WYSIWYG vs WYMIWYG would be very useful.
>
> --Andrew

[Chris Johnson-21]

On Sat, May 23, 2009 at 3:54 AM, Arancaytar Ilyaran
<arancaytar.ilyaran@...> wrote:
> Damien Tournoud wrote:
>> - It is doubtful that a WYSIWYG editor improve usability
>
> Hear, hear.
>
> BBCode and Markdown isn't hard to get into, and it's used on all forums
> I've ever seen.


I've got my own little rant here.

Folks who say WYSIWYG editors do not improve usability are myopic
programmers who I never want determining the specifications for
projects I work on for my customers.  Every customer we have demands
WYSIWYG as part of their deliverable -- and for good reason.  A lot of
their end users are barely capable of using email.  Expecting them to
learn Markdown or something similar is insane.

A lot of the time, my customers also expect to do things like
copy/paste from MS Word documents and have it "just work" as far as
formatting goes.  Making that work is even uglier and less reliable
than straight-up WYSIWYG.

However, it doesn't matter what we as developers think about the
crappy state of WYSIWYG editors and the impossibility of pasting
horrible Word formatting.  Our job is to make computer software work
better and more easily for the end users, not to force end users to
adapt to cryptic computer limitations.

End of rant.

Yup, all of the WYSIWYG editors out there have some sort of limitation
or another.  That's a technical challenge.  Can we solve it?  Or do we
throw up our hands and give up?

..chris

[Daniel F. Kudwien]

> However, it doesn't matter what we as developers think about
> the crappy state of WYSIWYG editors and the impossibility of
> pasting horrible Word formatting.  Our job is to make
> computer software work better and more easily for the end
> users, not to force end users to adapt to cryptic computer
> limitations.

Thanks.  Finally someone who understands the issue at hand.

> Yup, all of the WYSIWYG editors out there have some sort of
> limitation or another.  That's a technical challenge.  Can we
> solve it?  Or do we throw up our hands and give up?

Yes, we can.  Major parts of the challenge are solved already.

There is no "the editor for Drupal core".  In the same way you can have
multiple input formats for HTML, BBCode, Markdown or PHP, you can have an
appropriate client-side editor attached to each one of them.  Switching the
input format means switching the editor.  If you don't understand that, then
you don't understand the overall issue.

Also, we allow all Drupal modules to expose functionality to all editors.
Without requiring module developers to learn and understand gazillion of
different editor libraries.

Certainly, we still have to tackle some larger issues.  However, we are
slowly getting there.  If you want to help, just ping me.

sun

[Walt Daniels]

My sentiments, exactly! If the users can't use it without problems they will
leave you site for one that is more user friendly. Without problems means
whatever ugly hacks under the covers are needed to really strip Word junk.
They don't understand the need to use paste from Word (in tinyMCE) and it
gets it wrong fairly often.

-----Original Message-----
From: development-bounces@... [mailto:development-bounces@...]
On Behalf Of Chris Johnson
Sent: Saturday, May 23, 2009 4:20 PM
To: development@...
Subject: Re: [development] Status update: WYSIWYG support in Drupal core

On Sat, May 23, 2009 at 3:54 AM, Arancaytar Ilyaran
<arancaytar.ilyaran@...> wrote:
> Damien Tournoud wrote:
>> - It is doubtful that a WYSIWYG editor improve usability
>
> Hear, hear.
>
> BBCode and Markdown isn't hard to get into, and it's used on all forums
> I've ever seen.


I've got my own little rant here.

Folks who say WYSIWYG editors do not improve usability are myopic
programmers who I never want determining the specifications for
projects I work on for my customers.  Every customer we have demands
WYSIWYG as part of their deliverable -- and for good reason.  A lot of
their end users are barely capable of using email.  Expecting them to
learn Markdown or something similar is insane.

A lot of the time, my customers also expect to do things like
copy/paste from MS Word documents and have it "just work" as far as
formatting goes.  Making that work is even uglier and less reliable
than straight-up WYSIWYG.

However, it doesn't matter what we as developers think about the
crappy state of WYSIWYG editors and the impossibility of pasting
horrible Word formatting.  Our job is to make computer software work
better and more easily for the end users, not to force end users to
adapt to cryptic computer limitations.

End of rant.

Yup, all of the WYSIWYG editors out there have some sort of limitation
or another.  That's a technical challenge.  Can we solve it?  Or do we
throw up our hands and give up?

..chris

[Ryan Cross-3]

On Sun, May 24, 2009 at 11:06 PM, Walt Daniels <wdlists@...> wrote:
> My sentiments, exactly! If the users can't use it without problems they will
> leave you site for one that is more user friendly. Without problems means
> whatever ugly hacks under the covers are needed to really strip Word junk.
> They don't understand the need to use paste from Word (in tinyMCE) and it
> gets it wrong fairly often.

Do you know of any other site or WYSIWYG editor that handles M$ word
better than what's available?

I don't think there is one, otherwise I'm sure it would be quite
popular. I'd be happy to be proven wrong though. I just don't want
people chasing a mythical "perfect" wysiwyg editor.

[Kathleen Murtagh]

On Sun, May 24, 2009 at 9:19 AM, Ryan Cross <drupal@...> wrote:

On Sun, May 24, 2009 at 11:06 PM, Walt Daniels <wdlists@...> wrote:
> My sentiments, exactly! If the users can't use it without problems they will
> leave you site for one that is more user friendly. Without problems means
> whatever ugly hacks under the covers are needed to really strip Word junk.
> They don't understand the need to use paste from Word (in tinyMCE) and it
> gets it wrong fairly often.

Do you know of any other site or WYSIWYG editor that handles M$ word
better than what's available?

My team just recently had to solve this problem.  We created a new plugin based on TinyMCE's "Paste from Word" button that automatically runs based on an algorithm that detects if a user has pasted.

It's not perfect, because for instance it strips all styles from any HTML (so no right or center text alignment).  However, for a limited input format, its appears to have solved the problem we have.  It even works with Image Assist.  We no longer get complaints, the editor really is displaying what they'll get, and all the font formatting is consistent across the site.

Obviously, we need to bundle it up and provide it back to the community.  We'll be working on those tasks after the site's release.  However, you can still access it off the SCF github repository if you're interested:

http://github.com/benjamin-agaric/scf/tree/90aa5f4114bd468122c6a6b833d314b219600869/modules/custom/cleanword

(It may be out of date.  We fixed some critical bugs about two weeks ago)

[andrew morton-3]

On Sun, May 24, 2009 at 9:06 AM, Walt Daniels <wdlists@...> wrote:
> My sentiments, exactly! If the users can't use it without problems they will
> leave you site for one that is more user friendly. Without problems means
> whatever ugly hacks under the covers are needed to really strip Word junk.
> They don't understand the need to use paste from Word (in tinyMCE) and it
> gets it wrong fairly often.

One of the things that I found insanely frustrating with pasting from
Word was that depending on which browser you pasted it into you'd get
an entirely different DOM tree as a result. IE6 would end up with
something really broken while FF3 would actually handle it pretty
well. It added another agonizing level of complexity to the testing
process.

andrew

[Bryan Ruby]

Ryan Cross wrote:
> Do you know of any other site or WYSIWYG editor that handles M$ word
> better than what's available?
>
> I don't think there is one, otherwise I'm sure it would be quite
> popular. I'd be happy to be proven wrong though. I just don't want
> people chasing a mythical "perfect" wysiwyg editor.
I've found that a number of WYSIWYG editors work much better in Internet
Explorer than say Firefox when doing a copy/paste from MS Word (2007).
Don't ask me why, it's just an observation.

There is and never shall be a perfect rich text editor, but that
shouldn't be a reason for not implementing a WYSIWYG editor.  In fact I
don't know a single Drupal core module that is perfect but it hasn't
stopped us from loving Drupal.  I believe the original point of this
thread was not a discussion on the advantages and disadvantages of an
RTE. Instead, the discussion is how best do we move forward in
implementing WYSIWYG in Drupal.
 
On a side note, I'm a huge fan of the WYSIWYG API (
http://drupal.org/project/wysiwyg ).  Bravo to this project and others
in recently moving the third party code over to "|sites/all/libraries/"
|it should make future Drupal upgrades much easier to manage.

Bryan
||

[Thomas Zahreddin]

Hi,

fckeditor does a good job:

http://docs.fckeditor.net/FCKeditor_2.x/Users_Guide/Common_Tasks/Cut%
2C_Copy_and_Paste

fckeditor has a paste from word option, Point 3 on the website

best
Thomas Zahreddin

[Bill Fitzgerald]

>
> On a side note, I'm a huge fan of the WYSIWYG API (
> http://drupal.org/project/wysiwyg ).  Bravo to this project and others
> in recently moving the third party code over to
> "|sites/all/libraries/" |it should make future Drupal upgrades much
> easier to manage.
>
>
Second the kudos for the WYSIWYG API -- it's also worth noting that when
using both Tiny and FCK, the WYSIWYG API offers an option to have the
default paste clean up formatting. This simplifies things for the end user.

This, in combination with the work on Filefield inserts, actually makes
for a WYSIWYG experience that approaches something that will satisfy end
users without horrifying developers.

And, fwiw, I am no fan of text editors. But I am a fan of meeting client
expectations. The WYSIWYG API offers the hope that these will not always
be mutually exclusive attitudes.

Cheers,

Bill

--

Bill Fitzgerald
http://funnymonkey.com
FunnyMonkey -- Click. Connect. Learn.
ph. 503 897 7160

[Karoly Negyesi]

If we were here to satisfy clients with core then all the core files
would be writeable by Apache so you can just update them from a
browser. We do not do that. However, we DO recognize the need for that
and I have spec'd out somewhat Plugin Manager which Joshua Rogers has
written as a GSoC project last summer and is now headed for core.
http://drupal.org/node/395472 have you reviewed it?

In a similar vein, if we were to satisfy clients who (to quote
webchick) think a patch is something you sew on a jacket, we would
have TinyMCE or some horror in core already. Instead, NOONE paid
attention to Stefan Negtaal who pointed an editor that COULD be a core
candidate and instead yelped about Word copy-paste. Word is a
proprietary product and I be damned if we deliver a crap product
because of something that's not even open source. This does not mean
we do not want to lower barriers -- for example, one of the design
goals for DBTNG was to enable MS SQL and Oracle support. Have you seen
that Andrea wrote an Oracle driver? http://drupal.org/project/oracle
Did you help him? That's soemething a lot of clients want and I *bet*
it wont pass the tests 100% right now.

To sum up my angry rant which was trigerred by the word "client":

*) I am very much in favor of enabling techniques. The first is in
http://drupal.org/node/125315 note the people working on it. I have
not seen many people bleating in here helping there. Further patches
will find me helping, too.
*) I will fight very hard against a WYSIWYG editor in core.
*) I will help as much as I can without significant JS skills adding a
markup editor with live preview. Steef's a strong a candidate.

Regards

NK

[Karoly Negyesi]

In a much lower voice, have you seen that Steef largely stopped
contributing? Guess why: mostly because the old small community
feeling of Drupal is waning and there is too much "clients" around.
Think.