Hacker News Reader

Comment by Samuel_Michon | Hacker News Reader

I think the solution for content creators and content managers is not to copy and paste from full fledged word processors like MS Word, LibreOffice, and Apple Pages. Write plain text documents in Notepad (Win), TextEdit (OS X), or whatever plain text editor their BSD or GNU/Linux distribution offers. If they want to add styling, have them use Markdown or Textile and have a CMS that parses it.

For small sites, I use Textpattern. Contributors can write content in plain text with Textile tags (if they choose to do so).

For larger sites, I use Drupal. Contributors can write content in plain text with Textile or Markdown tags (if they choose to do so).

That way, the brand gudelines are upheld and contributors don’t have to think about styling too much (and if they want to disrupt, they can’t).

View on HN

> the solution for content creators and content managers is not to copy and paste from full fledged word processors like MS Word, LibreOffice, and Apple Pages

A solution that boils down to "take all the tools in your workflow that you're already familiar with and throw 'em out the window" is not going to go over well.

Those of us who work in the content-management space have been trying to get people to understand "pasting from Word is bad and will break your heart" literally for decades now. It never works. Word is the only composition tool many of these folks are familiar with, and that familiarity has only come because (from their perspective) they've had to fight with its idiosyncrasies for so long that they finally know where all the land mines are. The idea of having to go through all that all over again with a new program is frightening, so they hold on to Word with all their might.

It's possible that eventually Word will become less of a problem, not because it'll get better but just because a generation of writers will grow up who are more familiar with Web writing tools than offline ones. But we're at least a couple of decades out from that being the case, alas.

> If they want to add styling

The problem for a lot of users is the disconnect between a logical style (the actual boldness of the text) and representations of that style. If you haven't learned to handle this kind of abstract symbolism, plain text markup formats just don't make sense to you. Your brain instead registers it as a combination of "this editor doesn't have bold for some reason" and "the computer garbled my copy and made parts of it bold for some reason" without ever drawing the connection between one and the other.

This is only really an issue in places where abstract thought is seen as an innate ability which can only be tested for and not taught to people. Unfortunately this includes the US.

I read your comment several times. I don't understand the distinction you're making. I feel dumb. Could you explain it in another way? I'm sure your comment has value, I just don't understand it.

In languages like Markdown and Textile, one doesn't need to worry about presentation, it's all about semantics.

The distinction I'm alluding to is simply "the map is not the territory." In other words, in the same way that you can have something which represents a tiger without actually being a tiger (eg. the word "tiger") you can have something which represents "the boldness of this text" without literally being the boldness of that text. The double asterisk notation in Markdown, and the <b> tag in HTML, are symbols for the boldness of the text they annotate.

What I'm saying is that untrained users have trouble with the idea, fundamental to markup languages, that some text can represent attributes of other text. To such users, an asterisk means "the text has an asterisk in it." They cannot reinterpret asterisks as markup without relearning the way they look at text itself. They're used to having the territory laid out in front of them, and all of a sudden you're handing them one map and asking them to write another, but they don't know what a map is.

The distinction is exactly that between

    <p><b>some text</b></p>

and

    <style type="text/css">
      .emphasized { font-weight: bold; }
    </style>

    <!-- [...] -->

    <p class="emphasized">some text</p>

One specifies "this text shall be bold"; the other specifies "the semantics of this text require that it be emphasized", with precisely what 'emphasized' means handled elsewhere, in the CSS which defines how the class 'emphasized' shall be rendered -- which, given appropriate media queries, might appear entirely differently depending on whether the document is rendered to a large screen, a small screen, to print, &c., &c.

Reply on news.ycombinator.com