21

I have a wiki-style application where users can create articles. Recently, some users have been complaining that our editor does not support copying rich text and formatting from applications like Microsoft Word, Excel, or certain web browsers.

The reason I don't want to add support for that (I actually purposely disabled the 'feature') is because of how dirty the submitted input is. When copying from Microsoft Word for example, lots of HTML tags are added.

Am I wrong in disabling this? What are the pros/cons of enabling or disabling rich copy&paste.

6
  • 2
    I think you are absolutely right, and if you get no good answers I'll try to tell you why when I'm not on an iPad. +1 for good question. Apr 2, 2012 at 20:09
  • 4
    If you use something like TinyMCE which I think is what WordPress uses, then it strips the rubbish from Word and cleans it up behind the scenes and actually does a fair job. Indispensible for those that create (or have been supplied with) content from Word - especially if not technical enough to find (or understand the need for) workarounds. Apr 2, 2012 at 20:15
  • @RogerAttrill: I actually am using tinymce with the paste plugin to weed out the tags. It's not 100% clean but I am satisfied with it. The users don't think so, however...
    – Tom Ryan
    Apr 2, 2012 at 20:42
  • @BennySkogberg: Thanks, I would love to hear your suggestions!
    – Tom Ryan
    Apr 2, 2012 at 20:42
  • 1
    Depends how you do this...I'm universally extremely annoyed when Word decides to copy styles from content
    – Ben Brocka
    Apr 2, 2012 at 20:49

5 Answers 5

10

The question you need to ask is:

Will enabling pasting of rich text add value to my application?

Will it add more users? Will it help retain users? Will it make them more productive? etc.

If the answer is "yes" then you need to weigh that against the cost - which in this case is the effort required to sanitise the input and the cost of not sanitising the input and having "dirty" text in your database or losing customers.

If the sum comes out positive then you should implement this feature.

Enabling the pasting of rich text will improve the UX - the user won't necessarily have to do anything more to their text to get it appearing how they like, as it will already be formatted to their satisfaction. There won't be the additional "reformat" step that your current implementation has. Of course, some users will want the ability to paste as plain text and reformat so the feature must be optional.

5
  • 1
    Thanks for your answer Chris. I understand the business aspects of this decision but I was more interested in how the user experience would be affected by choosing to allow rampant copy&paste. We really want to please the user, but in an elegant way!
    – Tom Ryan
    Apr 2, 2012 at 20:39
  • @TomRyan - Ah - I didn't make that clear enough.
    – ChrisF
    Apr 2, 2012 at 20:40
  • I take issue with "the user won't have to do anything more"; I often found myself stripping formatting from copied text in Word. The best part of that feature was that you could turn it off
    – Ben Brocka
    Apr 2, 2012 at 21:02
  • @BenBrocka - well it depends on the user. A technically minded user might well want to turn it off.
    – ChrisF
    Apr 2, 2012 at 21:03
  • 1
    Respectfully, I think this approach shows bad design practice. You're assuming that there are only two solutions (feature/no-feature) and ignoring all subtleties of the issue for a kind of benefits-bookkeeping approach. To view this problem as a designer, you must acknowledge that both obvious solutions have their issues (ugly html, messed up styling/annoyed users, extra work). The task of the designer is to find an elegant solution that acknowledges all requirements and makes everybody happy.
    – Peter
    Mar 26, 2013 at 12:39
5

In the web application I work with, pasting of Office material caused some significant issues (including embedded stylesheets that broke the entire page). But this is not an indictment of pasting actually... my recommendation is to allow pasting. But post-process the HTML submitted and remove all but allowed HTML tags. In particular, make sure to strip mso attributes, <style>, and <script> tags. I personally would go farther; remove all but very select basic HTML tags (<p>, <h?>, <strong>, <b>, <ul>, <li>, <br/>, etc) and clear all style, id, and class attributes completely.

This will allow you to paste in the HTML, but requests for specific fonts, margins, divs, spans and such will be removed. The formatting that is lost can easily be replaced if necessary, and this will (by default) cause all pasted content to conform to the standard stylesheet.

Exactly where you draw the line for allowed content is up to you, but I have found this to be an excellent alternative to wholesale blocking of formatting that usually pleases both parties. The only significant loss that I've seen with this method is paragraph options (margins, line spacing) and fonts... but I believe the end result (consistently formatted content) is superior because of this loss.

3

In general I think this is an example of the client describing their required solution not their problem. I presume, for instance, that the client uses Word to typeset web content because of a few useful features, like WYSIWYG, "Track Changes" and the ability to send around a document for discussion.

It's my guess (and it's only a guess, since it depends on your customer in this instance), that what they really need is the tool to develop over time to allow them to do their content drafting in the wiki itself, showing them a live preview of all type treatments, giving them flexible draft states to permit easy discussion and review and potentially even a nice "diff" interface to get something like "Track Changes" working in the web app.

All that may be overkill, mind you. The simplest issue here is figuring out a way to avoid Word doing its automatic pasteboard stuff that converts the copied text to HTML when pasted in a contentEditable field on the web. If you can get the input more-or-less in RTF format, the extent of the crazy formatting tags should be reduced.

2
  • I doubt that the client's users needs this app to have all the features of MS Word. MS Word already has those, and they're all happily using it just fine; they need this app to fit in with the way they work and not make its own rules about what isn't allowed. Jul 15, 2013 at 15:44
  • @vincebowdren I don't think they do need this app to have all the features of Word, and I acknowledged that I would consider doing as much as overkill. Nevertheless, it's not about the app "making its own rules about what isn't allowed", that's a feature of the platform (the web).
    – Kit Grose
    Jul 16, 2013 at 5:36
1

I agree with your decision, however, if your users truly need the formatting, you should enable it.

For example, I built an application to help recruit for product research studies. The messages sent out for clinical studies had to be reviewed and approved, and had to be sent out with the same styling and formatting as approved, i.e. a bold red title that defined not to eat for 24hrs before coming to the study.

I used TinyMCE to enable this, but it was still a headache, and it was very inconsistent, despite what many people think of it's 'auto-formatting from Word' capabilities. :)

1

Here are a few pros:

  • Copy and paste is a very heavily used feature - for example it is the single most often used Microsoft Word command.
  • Your application's rich-text formatting may be good, but honestly it won't be as good as MS Word. Certainly to most users who already know how to do word-processing in MS Word, and don't want to have to learn a new tool to do the same job.
  • Your application may support rich-text formatting; but unless the users can paste in formatted text, they will have to do it from scratch in every single article.
  • even if it's not the user themself doing the formatting in MS Word, they may be transcribing the information (including formatting) given them by someone else. If you don't let them paste the formatted text, they'll have to redo all that work.

Not the answer you're looking for? Browse other questions tagged or ask your own question.