Greetings everyone! I'm throwing in my hat for participation in the WYSIWYG discussion.
As we've noted in previous discussions, we currently have a serious problem with WYSIWYG editors not being Input Format aware. In D7 we'll get a nice luxury of #input_format (sounds awesome Gabór!), and we'll easily be able to combine the two into a single, well themed element. I've rigged up a temporary solution for D6 that I've posted to the the WYSIWYG project issue queue (patch forthcoming).
Here's a graffle of how I imagine the Input Format system working with the WYSIWYG framework.
Note: this is totally a mockup it is not a new WYSIWYG editor of any sort.
To make the WYSIWYG and Input Formats work together, we can simply add a "wysiwyg filter" to any input format to say that format should use WYSIWYG. Think tinyMCE profiles, but tied to Input Formats instead of user roles. Since we already specify Input Formats by role, we can eliminate duplicate permissions (if you have access to Full HTML, you automatically get tinyMCE, if you have Filtered HTML, you get BUEditor, PHP Code doesn't have any editor, etc.).
Also, as indicated in the mockup, we'll support multiple WYSIWYG editors on the same textarea. More details on this as code materializes.
| Attachment | Size |
|---|---|
| wysiwyg2.png | 54.91 KB |
Comments
Confluence
Love the mockup. The multiple tab design looks a lot like Confluence's editor (see here - http://www.wikimatrix.org/screenshots/screen_16_2.gif) - which IMO is what Drupal should be basing any design for D7 on.
Fuzz
http://teamipx.net
Fuzz
http://teamipx.net
Hi, Please check the
Hi,
Please check the http://drupal.org/node/125315, the Gábor Hojtsy is developing patches for the D7 for Textarea with input format attached, In the last patch of Wymeditor http://drupal.org/node/146624, this editor work with the filter format
That's some nice graffling.
That's some nice graffling. That's more or less how I pictured the ideal setup, although listing primarily by input filter seems a little more admin-friendly rather than user-friendly. I'm guessing most end users (especially the ones who use a wysiwyg) don't care what the name of the rich text editor is and in fact, names like FCKEditor, and BUEditor and TinyMCE could be off-putting for your average content admin. What makes more sense to me would be to have the input formats be in the tabs: "Plain Text", "HTML", "PHP Code" etc. and have the pulldown on the right list the available editors for that format (if any), or maybe just an enable/disable editor link if there's only one available for that input format.
Using tabs in the way I describe sort of violates the ideal UI principal of tabs. Tabs should show different aspects of the same data (which this would) but that strongly implies that switching tabs does not affect that data, but the input format of a text area is a persistent state. I'm not sure how I'd reconcile that. Maybe style the tabs differently or make it a pulldown, but on the left.
Ronan
Gorton Studios - http://gortonstudios.com
Tabs and selectbox are doing -almost- the same thing
I completely agree with that. Normal editors -non technical users- expect something simple, and probably all a wysiwyg editor. Other formats are for more specialized users.
The situation I see here is that there is a double control for the same thing: input format (BTW, users usually don't understand that is "input format") and editor. Since each editor has a input format that uses, this UI creates a double control for the same thing.
What if you use just one (tabs OR the selectbox) and specifies there the available multiple options?
Something like:
Regards...
--
EM
--
Eduardo Mercovich
Here's another idea
I'm late to this discussion but there still seems to be room for further ideas on this topic. I don't think textareas should ever have multiple WYSIWYG editors attached to them, as it can really clutter the interface and user's aren't likely to switch between different editors on a regular basis. It's a user preference setting in my opinion, so move it to the profile.
Now why are we still trying to hide important and useful information from the user? In all the mockups I've seen regarding input filter improvements none of them make it easier for the user to see what they can actually do within the textarea.
My idea is to have the filter information present 100% of the time even if there's a choice of several different formats.
Simply show the currently selected format and nothing else. If only one format is available then remove the select field...
I completely agree with
I completely agree with rowanw. Make the displayed information task centric and user friendly (i.e. step away from the admin centric world view). The average user should see simple, but accurate information and should have ways to dig deeper if he/she so chooses.
--
Christoph Weber