Styling the TinyMCE interface

One of the big problems with most web based WYSIWYG text editors is that standard  editor interfaces don’t provide any feedback about the horrors going on underneath the surface. WYSIWYG editors are often blamed for producing crappy HTML. However I think they generally do a decent job, it’s the users that screw things up by copying and pasting from Word or other web pages and generally doing the sort of unexpected things people do. But that’s not really the user’s fault; we can’t expect most users to know HTML or care if an H3 element is illegally nested in a P element. What we can do is create a nicer user interface that gives them more feedback on what they are creating.

I’ve created a style sheet for TinyMCE editors with the aim of providing some of this missing feedback; check out the demo page. Inspiration for this comes from WYMeditor and CSS diagnostics.

There are three main affects I want this style sheet to have on writers:

  1. I want the way the content is presented to bring them closer to the medium they are using. For instance, pressing the return key twice—a common way of typing in Word—produces empty paragraph tags; making these empty paragraph tags visually represented in the editor, means they look wrong. This gives feedback that pressing the return key once to create a new paragraph is the way forward. Similarly the heading tags are coloured in gradually lighter shades of blue, my hope is that this suggests the hierarchy they represent and not just that they are bigger than other text.
  2. Content copied and pasted from Word documents or other web pages  is still a major problem. This style sheet should show up a lot of the most common problems as errors or warnings, indicating to the user that they should re-enter the content using the proper dialogue or clean up the HTML (or call for help! ).
  3. There is only a fairly small subset of HTML tags that are needed to create standard articles. Often other elements might creep in from copying and pasting, legacy content or someone knowing a bit of HTML writing it themselves. If the writing interface gives feedback that these illegal elements are erroneous they can quickly be squashed, before they either don’t validate or break the front end.

It’s early days for this project yet, I’m sure I’ll have plenty of revisions as I delve deeper in the mysteries of TinyMCE and people’s writing habits but there are a couple of things I’d like to note:

Anyway, have a play with it, try and break it, and let me know what you think and how it can be improved. If there is any interest I might look at packaging it up some sort of open source TinyMCE plugin.

UPDATE:

Following on from the comments, here is a version experimented integrated in to the Visualchars plugin.

Comments (6)

  1. Adrian Sutton

    Wow, that’s seriously awesome. I’d definitely be interested in seeing this improved and developed further. I actually work for Ephox so do a *lot* of work with WYSIWYG editors and constantly work to find ways to make things easier for authors – this would help an awful lot.

    The trick to Word copy/paste that we’ve always found is basically to filter it very heavily and only keep the structural elements – with a nice looking stylesheet for the site, this usually gives the author what they were actually wanting anyway and looks quite nice. Plain text pasting on the other hand seems to strip away too much of the formatting and requires a lot of rework. Our EditLive! product has this Word filtering built in and we’re hoping to bring that over to TinyMCE in the nearish future as well. Better filtering, plus a stylesheet that gives structural information like this should be a pretty compelling solution to pasting from Word.

    The only issue this stylesheet introduces is that it no longer looks like the published content (ie it’s not WYSIWYG). Most users get pretty confused and frustrated when that happens. I wonder if some of that structure information could be combined with the real site stylesheet to get a best of both worlds view? Otherwise just having the ability to switch between the structural and design stylesheets would probably be viable as well.

  2. Spocke

    This is amazing stuff. Been meaning to add something like this to TinyMCE for quite some time. Maybe we could add this to the visualchars plugin adding menu to that button enabling the user to either display the block level formatting like this and/or the nbsp characters that it currently supports.

    I think a lot can be done when the code gets serialized so errors like a p wrapped in a h1 should be avoidable if we just match the contents against a DTD structure and remove invalid items. This is something we are planning to add to the 3.4 release when we rewrite the HTML serializer engine we currently have.

    What do you think, is this something you would like to contribute to the TinyMCE project drop me a mail if you are interested?

  3. edeverett

    Thank you both for your comments and encouragement. It’s great to get such a positive reaction.

    Sorry for not giving a thoughtful answer right now, but your comments raise interesting questions have given me a lot to think about. So a full reply will take some time to formulate.

  4. edeverett

    Ok, so now I’ve gather some of my thoughts.

    First a little background. The project that I was working on when I started to think about this was a largish content site where a peice of content might be displayed in several places on the site or in different media (PDF, RSS etc.) so I wasn’t really considering a direct, one to one WYSIWYG relationship of the writing what was displayed on the page. I was intending for this view to be the only view writers had (they could preview a page before publishing). From the feedback so far it seems that more users are used to a sticter WYSIWYG style than I expected (I’ve never beed the greatest fan of strict WYSIWYG).

    Spocke suggested that this could be incorporated in to the Visualchars plugin, so here is a demo of that (click the ¶ symbol). I think it works quite nicely. http://edeverett.co.uk/experiments/editor_display/new/examples/structure.html

    Adrian:

    “I wonder if some of that structure information could be combined with the real site stylesheet to get a best of both worlds view?”
    Interesting question. Normally WYSIWYG or markup style editing are diametrically opposed, but I think it could be possible to bring the two sides closer together. I guess that was one of my aims with this project. It might be possible to merge combine the two stylesheets in a way that does this, or it might be possible to show a more “markup” view temporarily on the element being edited. I think the challenge is likely to be providing a solution that is simple enough for users to understand. Presenting parts of different views of the content at the same time is likely to have a high cognative load creating a tricky user experience.
    I will think about this more, but I don’t have any answers right now.

    Spocke:

    I would be more than happy for any of this work to be contributed to TinyMCE.

    I’m personally ambivilent about using the visualchars plugin for this. It seems showing non-displaying characters and the structure of the HTML are related but different things. I’m not sure how different they are though and I’m probably too involved in my own thinking to be able to tell—however if people think it fits with the visualchars plugin then lets go with it. I guess that we can have a couple of settings and possibly two different buttons (to show the structure and non-displaying characters) so the website developer could choose to have both, either or combine them?

    ————————–

    Going forward, it would seem to make sense to split this into two area:

    1) Providing feedback to the user on the HTML they are creating in the editor.
    2) Providing feedback on errors in the HTML.

    Displaying the structure of the markup seems relatively straight forward—just enabling and disabling a stylesheet works. The current stylesheet would need to be expanded to take into account a wider set of HTML tags.

    There are a few issues I’ve not yet addressed:

    * Positioned elements elements and elements with specified widths might cause problems when borders or padding are added.

    * I guess we should remove any user defined stylesheet and revert to the default content.css when we are displaying the structure view to prevent any conflicts.

    I think the next step for will be to remove the error detecting CSS and get this part working nicely.

    The error reporting seems like a more complicated issue—not least because what counts as an error will vary from project to project. (Error detecting should primarily be done with Javascript, CSS is clearly not the right tool for this :-) I get the impression that a lot of this functionality is already included in TinyMCE in one way or another so I need to do some learning here about what is already done and what can be done. I would guess there will still be bits left over where a bit of visual feedback to the user could help.

  5. Adrian Sutton

    Hey Ed,
    The visual chars integration is what I had in mind for being able to toggle between views. I’m not sure if it should be part of the visual chars plugin or a separate button but it’s definitely on the right track for that.

    I’m still keen to have a “half on” mode though which shows the normal stylesheet but augmented with some of the information this stylesheet can show. It probably won’t completely replace the toggle-on full view, but would act as an in place reminder for users to actually think about this stuff. I’ve seen this work with the accessibility checking we added in EditLive! Initially we just had an accessibility report dialog that user’s could open, but most of the time they never thought to use it and it didn’t have much impact. Then we added inline accessibility checking (like spell checking as you type but for accessibility) which checked for just the most common problems and it made users think about accessibility a lot more so they then started using the dialog more as well.

    I’ll have to spend a bit more time thinking this through and write something up – might even be able to photoshop something to give a better idea of what might be possible, but wanted to get you a response in a reasonable time frame.

  6. edeverett

    Hi Adrian,

    The accessibility problem highlighting on EditLive! is interesting, I’ve not seen accessibility issues dealt with like that before. I can certainly imagine HTML problems being shown in a similar way. I’m struggling more with how this way of doing things can be used to show the structure of the HTML to the writer – it’d be great to see a mockup of your ideas when you have time.