In the Why don't D.O. and G.D.O. use a wysiwyg editor? thread, I suggested it might be good to start a discussion on specifications for a coherant and integrated WYSIWYG user experience in Drupal. This naturally starts at a distance from the priorities of developers, but it's my hope that it's still useful for discuss the issue from the perspective of end-users and site-builders.
Here is a a mock-up image which points to some of the things I believe an integrated WYSIWYG in Drupal must do well. There is a quick run down of the principles highlighted by this mock-up underneath.
Principles:
- Embedded, inline images are a vital part of a WYSIWYG editor.
- Formatting the image (setting it's size and layout) makes the most sense to the user if it is done in the same place as the uploading.
- The image layout options provided by the major WYSIWYG editors are deprecated and grossly over-complex. Site designers decide how much padding should appear around images, end-users simply need to be able to apply classes to achieve common layouts.
- Drupal handles line-breaks without extra mark-up, therefore a WYSIWYG editor for Drupal shouldn't add P and BR elements.
- End users with little HTML experience do sometimes have to edit the HTML code directly (when pasting social media embed code, for example). Therefore a WYSIWYG editor for Drupal shouldn't reformat white-space in the textarea.
- Pasting formatted content from other sources should only paste structural HTML elements that the editor is capable of handling, and no style or class attributes. Currently, WYSIWYG editors paste so many style attributes (even when "cleaning up" word processor content) that the HTML becomes unusable - even for those experienced with HTML.
- Names for block-level elements should make sense to ordinary people. If we decide to make H2 and H3 block elements available, we should be able to present these as "heading" and "sub-heading".
How far to people agree with this? What other needs and requirements are there? Is there anything from here that could be acted upon, and what would that take?
Comments
I like the mockup and the
I like the mockup and the idea.
One thing i would miss personally: The ability to access uploaded filefields.
I use filefields to upload Images to my node. So i can make sure that the images / files are uploaded to the correct place without needing the user to think about file-placement etc.
There are two great examples of WYSIWYG integrated into CMS: Wordpress and Joomla with JCE Editor.
I think Drupal could learn ALOT from those aproaches!
Greets,
Simon
No reason not to use file fields here
I make heavy use of file/image fields, just like you do. The scope of this mock-up only covers the WYSIWYG editor on a single textarea.
In fact, my preference would be to store the uploaded images as image fields attached to the node you're working on - much like the Inline module does.
This would be a really cool
This would be a really cool solution.
Are you planning to make a module or just rethinking WYSIWYG for Drupal?
Simon
Thanks
I am not personally able to write or develop modules, so I'm simply trying to encourage some broad thinking here.
However my livelihood is implementing Drupal sites, and the lack of a coherent WYSIWYG in Drupal is becoming an increasing weakness of what I can deliver. So, if the outcome of this was some agreement on a plan of action, I would like to help by incoirporating development phases for such an action plan into my own private projects - essentially funding others to develop or improve any Drupal modules. I'm a small developer who delivers fairly modest projects, so I'm not talking about big bucks, but if there's a good plan then a little can go a long way :)
Have you seen the Drupal Gardens implementation?
It covers most of what you outline, except the layout of images - which I agree is needed feature. In addition, Gardens includes other input formats like plain, safe, filtered and Full HTML It's not perfect, in fact the addition of these input filters causes user confusion - but that's not to say they're not needed.
-Filtered is there because you need a limited suite of options so that anonymous users have a suite of options that work out of the box for commenting
-Plain is there for mathematical or scientific needs. Almost all WYSIWYG editors have a plain option for this reason.
-Safe (the most arguable) and a usability problem in its own right, but the concept behind it that people left to their on devices, have no idea that images are not "safe." So while "safe" is a horrible solution, the problem behind it has meaning.
-Full is basically all HTML tags.
In addition to these, our users are also trying to embed objects like flash. So, so we're talking about what this all means right now. We haven't arrived at a solution, when we do, I'll post back, but the point here is that any standard also has to consider multiple input formats.
Drupal Gardens is still too complex
Drupal Gardens has pushed the envelope for inline media, but it's still peppered with the problems of all other Drupal WYSIWYG implementations:
Completely agree about the need to support multiple input formats. This is a killer feature with Drupal, and I love the way the WYSIWYG module allows you to set different editors for different input formats. That's been a unique and major achievement, so hurrah for sun and the WYSIWYG team.
I think the stuff I'm suggesting above needs to take place perhaps in the Media module space, or by the provision of configurations, plugins for the popular WYSIWYG editors, and perhaps some additional filters.
We are tasked with fixing all
We are tasked with fixing all of these issues. Just a matter of time.
Accessibility
Great work @Mark Nielsen
I think providing an option to include alt tags and captions would be sensible. Apparently discussions elsewhere have dismissed the need for alt tags, but I would have thought this was a pretty basic requirement for anyone trying to maintain an accessible site?
(Failing to find older discussions on including alt tag in solutions. Will update this post if I find 'em)
Donna Benjamin
Former Board Member Drupal Association (2012-2018)
@kattekrab
Alt text, captions, etc
Thanks kattekrab. Good point. Support for alt text and captions should be a basic requirement.