Status update: WYSIWYG support in Drupal core
<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_.
On Sat, May 23, 2009 at 8:41 AM, Daniel F. Kudwien <news@unleashedmind.com>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
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
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@gmail.com>
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.
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
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
On Sat, May 23, 2009 at 3:54 AM, Arancaytar Ilyaran <arancaytar.ilyaran@gmail.com> 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
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
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@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Chris Johnson Sent: Saturday, May 23, 2009 4:20 PM To: development@drupal.org Subject: Re: [development] Status update: WYSIWYG support in Drupal core On Sat, May 23, 2009 at 3:54 AM, Arancaytar Ilyaran <arancaytar.ilyaran@gmail.com> 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
On Sun, May 24, 2009 at 11:06 PM, Walt Daniels <wdlists@optonline.net> 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.
On Sun, May 24, 2009 at 9:19 AM, Ryan Cross <drupal@ryancross.com> wrote:
On Sun, May 24, 2009 at 11:06 PM, Walt Daniels <wdlists@optonline.net> 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/90aa5f4114bd468122c6a6b833d314b21... (It may be out of date. We fixed some critical bugs about two weeks ago)
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 ||
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
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
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
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.
Op 25 mei 2009, om 02:33 heeft Karoly Negyesi het volgende geschreven:
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.
True, I have nothing to add here. I'm glad that at least (by me, the very respected and legendary core contributor) Karoly noticed that I sort of gave up on drupal and I'm not contributing much at the moment. That *does* however convince me that I was - in some way - valuable to the drupal project in the past and did things which brought drupal to a higher level. It also makes me re-think my consideration of comletely abandoning drupal as a whole, although I'm not convinced yet. Not sure why I answered this e-mail, as it does not add some value to the discussion. But I had the feeling that I had to let you guys know, how I'm feeling at the moment and the way I'm thinking about drupal. Kind regards, Stefan
When I first read Karoly's response, my inclination was to let this drop, as I freely admit to not understanding the rationale behind Karoly's initial response. But, given that my statement -- "But I am a fan of meeting client expectations" -- has sparked some comments, I wanted to take a moment to respond. As I've been thinking about this, I have a hard time understanding the reaction to the word "client." I suspect that this is largely due to our client base -- we work mostly with educational orgs and non-profits; our clients, frankly, are awesome, reasonable people, doing great work. I feel very fortunate that our work (as a web development shop) supports their work (as people doing great things to try and make the world a better place). But, to state the obvious, many clients are not like that, and I suspect that when most people hear the word client, they think of corporate types who think that real issues can be glossed over with better marketing materials. In my time in the community, I have definitely seen the tensions between the developer community, and those who think that Drupal needs a makeover to appeal to a larger corporate audience. The concerns that Drupal could become too corporate are, IMO, very valid, and something that the community needs to watch for. In some ways, I see this mirrored in the discussions about what DrupalCons should be, but that's a broader topic than can be discussed here. WRT Word, Oracle, and MS SQL: these are all proprietary apps. In very general terms, when we look to support people (also known as users, or clients), we should look for functionality that makes life better for as many people as possible. The notion that "supporting people" equates with accepting lower quality code is just not true; shortcuts are not acceptable. So, any statements that "supporting feature x" will result in bad code need to fall under the weight of their own inadequacy. Bad code in pursuit of a real need is still bad code, and will always be unacceptable. In looking at the people who use Word, Oracle, and MS SQL, if an org is using Oracle, they are likely to have some resources on hand, in either the form of money, staffing, or both. In short, these folks are in a relatively resource-rich environment. It takes a fair amount of money to launch an app based on Oracle, and even more in recurring fees. Word, on the other hand, is used by many people on the lower end of the technology spectrum. In many non-profits/schools, the people typing in Word don't have access to support personnel. They just want to get their work done. In short, these are the people/smaller orgs who are *always* disempowered by technology -- and there are a lot more of them than there are Oracle DB Admins. When we look for solutions that help to empower people, it's *good* to target things that make life easier for people who have traditionally been shut out -- and this is more likely to be true of your admin staff working in Word than your Oracle DB Admin working for Monster Corporation X. Stefan -- fwiw, I hope you make the choice to continue on with your involvement in the community. Cheers, Bill -- Bill Fitzgerald http://funnymonkey.com FunnyMonkey -- Click. Connect. Learn. ph. 503 897 7160
I think many people will be happy with a(n easily customiseable/extendable) tag editor in core - even those who want a full fledged wysiwyg, if their only other option is no editor in core at all. I myself prefer a simple tag editor too - it also has this "ability" to strip out all the extra markup when copying and pasting from word... Ofcourse most developers, if asked for an opinion will choose the editor they like and personally prefer to be the one that is included in core, but that cannot happen, so what is probably needed is someone to lead the effort. Someone who has buy in with the developers to decide "This is the editor that we want in. Either it gets in or nothing" and after that point, I suspect most of the bike shedding will be less common and people may try to work on the actual issues to get that to happen.
I think it's easy and tempting but ultimately counter-productive to focus on who's right or really gets it or works in the real world. If it were a simple, one-sided issue, it wouldn't be a problem. Really, if you remove the specifics, it's yet another debate about what Drupal should or should not include. This seems natural and inevitable: the many flavors of *nix exemplify, in my mind, that even in the OSS world different people have different needs and want their needs prioritized first (security, usability, stability, maintainability, etc). It also seems pretty difficult to expect everyone to agree on what the community's needs are, let alone what the order is. (And hey, the founding members of the community have been pretty amazingly successful at meeting most needs through the modular design.) So while we could say 'fork it', walk away, or continue to have these passionate but inherently divisive discussions on a case-by-case basis; we could also recognize our common interests and gains by working together and focus on finding an inclusive solution. That doesn't have to mean compromise, it's not always a binary world. Globally speaking, I say we concentrate all this energy into discovering creative solutions. Warm Regards, Tim On Mon, May 25, 2009 at 11:25 AM, Naheem Zaffar <naheemzaffar@gmail.com>wrote:
I think many people will be happy with a(n easily customiseable/extendable) tag editor in core - even those who want a full fledged wysiwyg, if their only other option is no editor in core at all.
I myself prefer a simple tag editor too - it also has this "ability" to strip out all the extra markup when copying and pasting from word...
Ofcourse most developers, if asked for an opinion will choose the editor they like and personally prefer to be the one that is included in core, but that cannot happen, so what is probably needed is someone to lead the effort. Someone who has buy in with the developers to decide "This is the editor that we want in. Either it gets in or nothing" and after that point, I suspect most of the bike shedding will be less common and people may try to work on the actual issues to get that to happen.
-- Tim Loudon t: 781.686.6096 e: tloud365@gmail.com
Naheem Zaffar wrote:
I think many people will be happy with a(n easily customiseable/extendable) tag editor in core - even those who want a full fledged wysiwyg, if their only other option is no editor in core at all.
I myself prefer a simple tag editor too - it also has this "ability" to strip out all the extra markup when copying and pasting from word...
Ofcourse most developers, if asked for an opinion will choose the editor they like and personally prefer to be the one that is included in core, but that cannot happen, so what is probably needed is someone to lead the effort. Someone who has buy in with the developers to decide "This is the editor that we want in. Either it gets in or nothing" and after that point, I suspect most of the bike shedding will be less common and people may try to work on the actual issues to get that to happen.
It's not that simple. I have build sites for "clients" where we installed a WYSIWYG and it was good. I have built sites for "clients" where we installed a tag editor or wiki-style input filter, and it was good. I have built sites for "clients" where we gave them just the plain textarea and let them write tags themselves, and it was good. And I have sites where I would want to do a little of each for different textareas. Bottom line: Those who say that we have no need for a WYSIWYG editor and we shouldn't bother with it (whatever the justification given) are wrong. Flat out, unequivocally, wrong. Period. Those who insist that we need a WYSIWYG editor in core by default so that it's always available are also wrong. Flat out, unequivocally, wrong. Period. Drupal is a flexible multi-purpose tool, and in some use cases a fancy schmancy editor is absolutely critical. In others it would totally destroy the usability of the site. So what are we supposed to do with that? What we should always do when faced with that sort of dilemma: Make it as dead-simple to extend and customize as humanly possible. I want to be able to change between a heavy WYSIWYG of my choice, a tightly filtered set of manual HTML tags, an liberal set of manual HTML tags, a wiki-style syntax, and absolutely plain text only input... *per text area, per user, per user preference*, for multiple combinations of those. Why? Because I have run into use cases for every single one of those, in both personal and professional work. That's what we need to be building toward. The WYSIWYG API module is a very good step in that direction but it's not there yet; Think of this as the Filter system TNG, which desperately needs someone who can champion and drive that the way that the Menu API, DBTNG, and the D7 usability work does. And it goes deep enough that it's something that has to happen in core, especially now with Fields in core. If we don't think holistically like that, we end up with the body field teaser splitter button... A major WTF usability fail that has exactly one use case (blogs by people who can't write an HTML comment) that is one of the key reasons why Palantir does not use the core body field, ever. It's broken by the flawed concept that there is One True Input Workflow, which is simply not true. Yours is not the only use case or workflow that Drupal needs to support. Whoever you are or whatever your use case, that statement still holds true. --Larry Garfield
On Tue, May 26, 2009 at 5:58 PM, larry@garfieldtech.com <larry@garfieldtech.com> wrote:
Yours is not the only use case or workflow that Drupal needs to support. Whoever you are or whatever your use case, that statement still holds true.
--Larry Garfield
I think that is spot on, and perhaps should be promoted to the official motto of this list. For the record, I do not think that having WYSIWYG in core is the way to go. I'm quite comfortable with being able to tack on Markdown, with or without helpful buttons, WYSIWYG with HTMLawed or just use plain text based on customer preference. I think having the WYSIWYG API in core would be encouraging a specific workflow that core has no business encouraging. More importantly, I think the default response to any sort of "add x to core" shoud be a loud and resounding "NO". In my opinion, core should be as slim and lean as possible. We might consider having more distributions, like "Drupal ready to go with WYSIWYG, blog and image gallery", but adding that to the code weight being dragged around across thousands of servers would be wasteful. Saying "no" to adding more stuff to core would actually be a great way to reduce your carbon emissions ;) -- Kind regards, Mikkel Høgh
On Wed, May 27, 2009 at 6:16 AM, Mikkel Høgh <m@ooh.dk> wrote:
More importantly, I think the default response to any sort of "add x to core" shoud be a loud and resounding "NO". In my opinion, core should be as slim and lean as possible. We might consider having more distributions, like "Drupal ready to go with WYSIWYG, blog and image gallery", but adding that to the code weight being dragged around across thousands of servers would be wasteful.
Not to pick on you specifically but I think this kind of a rigid, absolute thinking is actually as harmful to the project as the idea that core should be all things to all people. In my mind core should be about providing APIs that enable contrib. So while I'd agree that Drupal core should probably not ship with a WYSIWYG editor, it should provide APIs to make it easy to add them in contrib--the subject of this thread is WYSIWYG support after all. Any time you have 5-10 modules doing roughly the same thing in incompatible ways it's time to look at creating core APIs to allow them to work together and not duplicate the same functionality. The successful examples that come to my mind are node access modules from 4.7 to 5 and file modules from 6 to 7 (though it remains to be seen how well the file API works in practice). andrew
On Sun, May 24, 2009 at 9:06 AM, Walt Daniels <wdlists@optonline.net> 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
On Sun, 2009-05-24 at 11:55 -0400, andrew morton wrote:
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
The reason for this is that the <div contentEditable="true"> that is used to provide the WYSIWYG editing is implemented by the browser rendering engine and not javascript. Raj
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
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.
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
participants (22)
-
Andrew Berry -
andrew morton -
Arancaytar Ilyaran -
Bill Fitzgerald -
Bryan Ruby -
Chris Johnson -
Damien Tournoud -
Daniel F. Kudwien -
Dave Myburgh -
Karoly Negyesi -
Kathleen Murtagh -
KOBA | Hans Rossel -
larry＠garfieldtech.com -
Mikkel Høgh -
Naheem Zaffar -
Raja Sekharan -
Ryan Cross -
Stefan Nagtegaal -
Steve Edwards -
T L -
Thomas Zahreddin -
Walt Daniels