The actual act of editing something by trying to manipulate its output representation is usually painful, which is why WYSIWYG sucks for anything but demos to people who buy software but don't have to use it. The one thing it does get right is live editing, but you don't have to do WYSIWYG to get live editing -- you can just have a splitscreen with a sane, editable, logical representation on one side and an instant preview on the other.

Years ago I did exactly this for an internal CMS. The preview window used the same renderer as the front end, and there were various dynamic controls the authors/editors could use to control content, reference other content, etc. The preview window would update as they typed and always look like the current styles. If someone went overboard with direct styling, it would be painfully obvious during review, since reviewers first saw the raw content.

The system also had a "cheat sheet" which would show technical writers all of the supported styles and snippets in both literal and rendered forms.

The text you are writing will be read on smartphones, tables, PCs, and TV. It will have different layouts, e.g. depending on screen size. Which one do you want to preview?

There's no way around thinking about your use-cases and you're not going to convince designers to not want to see what the end product actually looks like.

Stipulating that point, though, perhaps the solution is to keep designers at a higher level of granularity -- to have them produce designs for "large screen", "small screen", "mobile", "print", &c., including general ideas of how body text shall appear, but leave the more granular detail to someone who's not so much wedded to pixel-perfection, but instead understands that the same content will necessarily look different when differently rendered, and who can understand and accommodate those differences to produce a result that works well across all of them.

It is almost as funny as the request that a logo must use the "Pantone 1337" color. It probably is not representable in RGB and nobody has a color-calibrated screen.

Can I quote your response somewhere on my website to explain the idea of LIVEditor?!

Firefox: https://addons.mozilla.org/En-us/firefox/addon/lazarus-form-...

Chrome: https://chrome.google.com/webstore/detail/lazarus-form-recov...

Safari: http://getlazarus.com/download

ALSO NOTE: Lazarus 3 doesn't save WYSIWYG editors yet, this is due to a Chrome bug (http://code.google.com/p/chromium/issues/detail?id=20773) which prevents us from accessing the iframe that is used to display the editor. There's little I can do until this bug is fixed, sorry.

The problem is that there is a learning curve to markdown, and while it's a small learning curve, it's still a hurdle. Toolbars and pseudo-WYSIWYG editors that output markdown are good baby steps. Fortunately, it's becoming more commonplace and picking up steam outside of developers with integration on sites like Reddit.

I once developed a specific transformation engine to convert Word documents to a given schema -- if they respect a set of rules that the transformation engine enforces.

Authors will always want to use Word; what would be interesting would be a generic tool to avoid the copy-and-paste step, but the "genericity" part is very hard...

Short of this, I built a small utility that converts rich text to Markdown: http://markitdown.medusis.com

It can be used to copy-paste from Word (or any rich text) and retains all formatting that core Markdown supports; it runs in the browser, locally (no roundtrip to any server) so no one should be able to see the content you use it for.

The goal would be: release just the basic functionality we have now with key improvements to deployment and obviously making it work in all modern browsers, then iterate from there according to customer demand with features (including things like editing from tablets and mobile devices) being prioritised by engaging with our user base.

Basically we've just spent too long working on this with absolutely no engagement with our target market (designers/devs) so we want to get it out in the open and see if it's actually worth finishing.

EDIT: If what you're referring to is the content being produced, then the fact that the markup and editing experience is so highly structured and the fact that the user is unable to put any presentation logic (fonts/sizes/styles etc.) arbitrarily in with the content unless you, as the designer, have explicitly allowed them to do it, the format is so reliable that repurposing the content to different devices is very safe and reliable -- ie. it doesn't really matter that the content editor can't preview on multiple devices, because you know that whatever they enter in, the format will be so predictable you can make it look good on any device.

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).

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.

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.

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

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.

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

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

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

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

[1]: http://en.wikipedia.org/wiki/Help:Table/Introduction_to_tabl...

[2]: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheats...

[1]: http://madebymany.github.io/sir-trevor-js/

If you put your email in at the end you get access to a full demo that shows you all the features of the full CMS. Thanks for checking it out!

We need to segregate data from presentation. More importantly we need to give users a choice in how their data is presented instead of forcing a particular design or presentation of the content on them.

If a user can choose how they want to read an article (tablet? desktop with lines of text that run the full width of the screen? phone? terminal window?) we should let them and give them options. There is no best way to present data because users are not all the same robotic machine, some prefer one format some prefer another. There is no universal best.

Why can't I read HN's content using reddit's design? Maybe I can and I haven't tried. My point is that most of the content we consume on the internet is text, pictures and video. I hate the youtube interface. Why the hell can't someone write a better one and then I view youtube's data that way?

Dissociate the front end from the backend. Send all the interface designers off to design frontends for any website that with a certain kind of data. Let the user pick which frontends they want for which website and then the website can send the data. Compensate the the frontend designer by giving them a portion of the revenue or something, or have users pay a little bit for frontends on an app store or something, or have websites pay the designer of the most effective frontend to use it as the default for users who don't bother to choose their own frontend(smarter people than me can figure out how to monetize this).

Am I insane to think that for a huge portion of the content on the web data and presentation can be completely segregated? Text is text, pictures are pictures, figures in papers are figures. Sure, a data person might insist that their data must be presented in a certain way, but isn't that just saying "fuck the user I'm and artist?"

What would it take for a system like this to become reality? (in scientific publishing what it would take is publishers releaseing the raw xml versions of the paper--which they already have--and it would make stuff like citations a thousand million times easier to deal with)

It already is a reality. If you want to divorce content completely from presentation, you can do that right now, today, with HTML & CSS. There's no technical hurdle stopping you.

The problem is that understanding that "content" and "presentation" are two separate things requires people to work at a level of abstraction that most of them are not used to working at. In the tools they're familiar with, it's all mashed together. (You can separate the two in Word with things like document styles, but that's not how Word works by default; and there's little practical benefit to doing so for small documents anyway, so few people discover it unless a more advanced user takes the time to teach them.) So when you try to teach them to do their work in this new way, it feels to them like you're just adding unnecessary complications to their workflow. They then reject your tools as pointless egghead stuff, and you for trying to foist them on them.

It's a cultural problem, in other words, not a technical problem.

Sorry, but I don’t buy that. The very best presentation is almost always customised to the material it conveys.

We try to separate content and presentation as a compromise, partly because it’s too labour-intensive to craft a bespoke presentation for every little job, and partly to separate skill sets because someone can be a great author but suck at design. But it’s still a compromise, and someone who both knows their material and knows design will often be able to create a more effective presentation of that material than they could if they were constrained to some pre-determined, standardised box of presentation tools.

By the same principle, it’s not necessarily an advantage to let someone viewing that content customise the design arbitrarily, because it’s almost axiomatic that such a person isn’t yet an expert on the material. They don’t know which ideas are the important ones that the author wants to build on, or which relationships in the data are the most enlightening ones to explore. A well made presentation, created by or in collaboration with a subject matter expert, can direct the viewer through the material in a more considered way.

To me, it makes no more sense to use a medium where the viewer has to make presentation choices than it does to send them a few spreadsheets of raw data and let them write their own content or plot their own charts.

I do not think the analogy to spreadsheets applies here. There are (at least) thousands of perspectives on/presentations of scientific data that are completely meaningless. In that case the perspective and presentation matters (though the sharing the original data opens up the opportunity for others to find new perspectives as well, though at the moment they do need to 'plot their own charts')

That said, once the author has chosen the perspective that perspective will be conveyed via some medium. At that point the data should be able to stand on its own. I used the word presentation, but 'layout' is probably closer to what I meant. If we take my use of presentation literally then we agree and this is why someone posting slides for a talk without also posting the talk is a terrible idea.

With regard to expertise, I would argue that everyone is an expert on what format/layout they find easier to use (sort of like why we let people move their windows around in a window manager instead of forcing them all full screen, re: tablets are major offenders here). I'm not talking about letting people change the words here or put the legend for figure 1 with the data for figure 3.

Right in my browser, firefox, and maybe yours, I can set the default fonts, sizes, and colors, and I can force sites to use my settings. This is a partial step towards where you're going. Most designers will not simply use the foreground, background, serif, and sans-serif fonts that a user has set. This could be a good thing, since the majority of people don't even know that these options exists, but it is forcing a single design upon the users.

https://addons.mozilla.org/en-US/firefox/addon/stylish/

In the old days (yes ... I'm old), we used WordStar on CP/M and we were careful to use our limited formatting features to maximize the impact of our words. We had bold, underline and (sometimes) even italics. When we composed our text, we assumed we'd use 55 of the 66 lines on the paper, and 75-80 characters across the page (depending on margins). We did this because that's what a 12 CPI typewriter would do. If we moved to a different printer, it might not be able to produce the exact same document, but with a few exceptions, we could live with the changes to the line wrapping and simply print it.

The problem introduced to printing when laser printers arrived (yes ... you could do cheesy images on dot-matrix printers) was that we now had to flow around images, account for multiple text sizes and pitches. As the web matured, we never quite completely separated the text formatting from the layout. My recommendation is that you focus on the formatting of your text when writing. Let the designer figure out how the layout needs to change when "responsive design calls".

Many large organizations do more than that. Apps, feeds, radio, print, eBooks. There's more than just the web.

Inline editing privileges one of these over the other, which can be a misnomer. Making editing on the web is great, but we need to be careful that our tools aren't too closely coupled to web display where inappropriate.

One of the more interesting challenges was the mismatch between the structure of Word docx files and HTML. Whereas HTML has plenty of nesting, docx files have a comparatively flat structure. For instance, suppose you want a nested list of depth 2 that looks like this:

    * Outer
        * Inner

If anybody's interested, I wrote a Word to HTML converter for node.js using the same ideas: https://github.com/mwilliamson/mammoth.js

I don't know the right solution, I've tried just about every editor and nothing seems to stop the Word to CMS copy/paste issue. Maybe the solution is to build a Word plugin to publish to CMS that cleans up the content as it publishes?

I'm actually thinking about giving this a go (I guess I need to purchase a Word license at first).

The office I work in is a very heavy copy-driven office, with multiple publications and multiple clients. You can tell how old a Web-based client is based on the way it handles copy flow. The oldest one relies on Microsoft Word; my program relies on a workflow using Markdown and Editorially—one I've advocated for elsewhere. The reason the older program is sticking with Word is not because the writers and web editors prefer it; rather, the copy editor prefers Word because of its track-changes functionality. It "just works" for them.

But ultimately, it's causing major issues for the web editors, because they have to put in a lot of extra work to add in links and formatting. It's a waste of everyone's time to deal with extra workflow with a product designed for a medium many people are no longer even writing for. Which is why I've made an effort to find alternatives to Word for our Web properties.

We need to write flexibly in the internet age; Word complicates and adds extra steps to a medium where good ideas need to be organized, quickly. I don't want my writers to have to worry about extra steps or formatting—I want them to write good stories.

That's why I use Markdown. It's why I sell my co-workers on writing in Mou and editing in Editorially. We do not have to stand for an outdated system. We can improve it, step by step.

We no longer need to print or typeset our content. We need to start acting like there's nothing standing in our way besides good writing and editing.

      There are three spaces * for content people – not creators,
      because not all content people create loads of content. Some just
      manage it – push it from here to there. Those places are:

   1. A space for writing. For writing and structuring.
   2. A space for management. For adding meta data, workflow, 
      configuration and managing roles and people.
   3. The website space. Basically your website. A place where 
      you begin the access user journey. Or preview your content.
      Generally the starting points for lots of little 
      administration tasks.

I've beat upon the perl code a bit but tracking down the 'paragraphify' bit is stuck in a regex pulling stuff apart. In my custom version I attach a different style to paragraphs in lists than ones in the document. This helps but there are still edge cases that are very annoying.

You can change it via CSS. Just add to your <ol> or <ul> the following: list-style-position: inside. The numbers/bullets consequently become part of the text.

My preference for styling lists is to leave the numbers/bullets outside but apply a margin-left to the lists so that its numbers/bullets fit inside the main wrap.

In fact, the author of the post has previously written a hugely popular series about typography that specifically mentions this choice: http://www.markboulton.co.uk/journal/five-simple-steps-to-be...

Good interfaces tend to be based around the principle of least surprise. But in a typical WYSIWYG editor it is commonplace to be in a situation where you don't know what will be produced when you press a key or press enter. The purpose of tools is to bring complex problems under control. To make a bridge between the underlying problem space and a set of controls that are intuitive for a user. WYSIWYG does a poor job of doing that.

One of these fellows spent his personal money to get three copies of his book laid out, in three different fonts. The look of the book was that important to him.

Am I supposed to lecture him that he should be thinking about "logical structure" not appearance? That I know what books are about more than he does?

I publish printed books for a living. I’ve been involved in the design, editing, and marketing of printed books for 20 years.

Unless the person you speak of self-publishes, he doesn’t pay anything for the lay-out of the book. If he does self-publish, and he has retained someone to make it into a half-decent book, then yes, that person should advise him about logical structure and appearance (depending on what that person is paid to do.) And yes, hopefully, the person he pays to help him does know more than him about creating books and shouldn’t be afraid to give his professional opinion.

Remember, a manuscript does not a book make. Experienced authors know this and value publishers.

I've helped a few authors get set up with their own websites, and the same concerns translated. They cared very much about how the site appeared, and had intelligent opinions about why that was the case. They weren't web ingenues -- they'd been reading other author blogs for years. Why would their concern with the appearance of the written word change when that word was online?

I can't name names, but these authors were far from self-publishing. They had substantial contracts from major houses. Their books were all covered in the NYTRB. The publisher of course paid for one lay-out of the book, but it was not customary to cover three. That's why the author used his personal funds -- for the extra two lay-outs.

our flow is like:

* does content have more than X number of words? * yes: prompt if the content has to be promoted as special "tweet" like feature * is the content tagged as Y and Z , or A, or B and C? * yes: prompt for other ways to promote the content. * does the content include video? * yes: prompt if the content needs to be featured in video playlists in a section page. * is it also tagged as D? should it be promoted in another section's hot-play list? * ...

our content people start with simple form asking for title, author, tags, and content (html). the content is parsed to see if any of our media (image, video, audio) is embedded. if our games are included... etc. And depending on the title, tags, author, content new input fields are injected dynamically.

order of dynamic fields are carefully chosen so that workflow is optimal.

we initially went with contenteditable blocks (or components). that failed miserably: database became complicated. We ended up building something similar to DOM tree in database.

start with a simple form. analyze user input. dynamically add/remove more fields.

If the audience is management, the gain is control. "You just spent umpty million dollars redesigning your visual identity, you don't want some low-level copy jockey deciding to throw all that out and publish a page on your site entirely in Comic Sans, right?"

If the audience is the people who actually have to use the software, the gain is simplicity. "Look at this editing window from your current system. It has four toolbars, with fifteen buttons on each one! Do you really know what all those buttons do? Do you really want to be responsible to your boss if you hit the wrong one and screw something up? Now look at this other editing window. Isn't it clean? Doesn't it look easy to use?"

Surely that is the problem? Wouldn't the truly disruptive question be "How do I automate those who push content from point A to point B"?

With the advent of the iPad, we've a surge towards fixed layout.

Go figure.