Wysiwtfftwomg

I'm pretty sure that what people want when they ask for WYSIWYG is live editing -- they don't want a "compile" step in their editing process, it's a gigantic productivity sink.

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.

I suspect many people create their content in Word because they have learned the hard way that sometimes, when you click "Submit", the page goes blank and you lose all your work.

This was a bit difficult to follow, but if it says what I think it says, markdown is a step in the right direction for device-agnostic content. With markdown, the content creator is not responsible for design and layout - this is handled independently by a designer, or several designers, with different designs for different outputs (desktop, mobile, pdf, ePub, etc). One major upside to markdown is that it can be written in any text editor on any device - from desktop software (notepad) to forms in a browser. Another upside is uniformity - with multiple writers collaborating on content, or if a specific style should be followed, there's little to no possibility for deviation - just write some '##' for headers and '-' for lists and the output always looks uniform.

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

Once we go beyond plain text editing, WYSIWYG becomes quite useful. E.g. even a simple table looks ugly in wiki[1]/markdown[2] format, and manually aligning columns with pipe characters is painful and time consuming. Then there are images, charts, TOCs, footnotes, and many more content types that cannot be intuitively represented in plain text.

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

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

There seems to me that there is a solution to this on the web and perhaps elsewhere (scientific publishing comes to mind for me).

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)

I clicked on this link due to the simply awesome title, but realized the author had a great point. When asking "how does this look" what we really mean is "is this rendering the way I want". He posits that to properly answer this question, you must ask "on what", but my feeling is that you need to split the question into textual formatting (which can stay the same on all devices) and layout (which might be adjusted for the device).

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

Inline editing makes perfect sense if the only thing you ever publish to or plan to publish to is the web.

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.

I used to be a developer for some technical websites (publishing articles, blogs, newsletters, that sort of thing), mainly around SQL Server and .NET. Almost all of the authors used Microsoft Word, the main value being familiarity and using Track Changes. I came to appreciate Track Changes when I wrote or edited the occasional article, and I can't imagine it would be easy to find a replacement for the functionality that would work smoothly enough to justify convincing all the authors and editors to switch. Fortunately, the authors and editors were pretty good about using the house style in Word, meaning that the articles were semantically marked up. I wrote a converter that did a pretty good job of generating clean HTML from the source Word, mainly by mapping Word styles to the corresponding pieces of HTML.

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

One way a docx (XML) file can represent this is a paragraph element with the style "Bullet1" (and the text "Outer"), followed by a paragraph element with the style "Bullet2" (and the text "Inner"). The two elements are completely separate, and you have to infer that they're part of the same list, and that the second bullet is the child of the first. Once you've done that, you can generate the corresponding HTML, which has the inner list as a child of the outer list element.

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

As someone trying to solve the problem of Word to CMS copy/pasting, this is sadly what the majority of people do. As someone trying build build responsive websites I see people adding a bunch of spaces to center align instead of using the "center align" functionality this kills me.

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?

This issue is been one I've been thinking about a lot lately—at least from the writer's perspective.

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.

One of my least favorite things about markdown:

      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.

See how the numbers sit outside the left margin? Or worse you've styled paragraphs and MD has chosen that your list elements need to be wrapped in p /p pairs and suddenly your bullets or numbers are sitting all alone while your paragraphs race over to the right margin.

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.

Maybe we just need to wait this one out? The problem is due to the fact that the current batch of content creators/managers learned text entry on word processors, but that must be changing. I'm guessing word processors had to shake of the legacy of the typewriter. Now we need to slowly shake off the legacy of the desktop word processor.

The problem with WYSIWYG is that it solves the wrong problem. Sure, what you see is what you are going to see, but that's irrelevant. What you care about is being able to change what you see. And that is tied up with all sorts of invisible context that you can't see.

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.

I couldn't even tell what argument the author was trying to make. The post seemed to be complaining about people using Word to write content. Then later on suggesting a CMS should be discrete applications. Isn't Word a discrete application?

Pseudo-WYSIWYG is enough in most use cases: the user doesn't actually want a pixel-perfect view of the final rendering - he just wants familiar graphical hints of his document's structure.

I used to edit books, and had the privilege of working with a few well known authors, people whose names you'd know if you follow fiction.

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?

a dynamically structured <form> is much faster for content people to work with than contenteditable crap.

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.

I'm yet to find the right way to have clients "buy in" to the concept of limited wysiwig functionality, as it can be hard to explain what they're gaining in return without long-ish term exposure to the underlying technologies. Maybe an open-source document would be handy to help us get the key points across to "content peoeple"?

Here's a serious question: what exactly is a "content person" when they clearly don't create content? According to the article, they push data from A to B.

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"?

Responsive Design is what eBooks had since the first ePub spec. The ability of the user to control all aspects -- typeface, type size, line spacing, justification on/off.

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

Go figure.

This is precisely the problem we're solving with http://www.decalcms.com/ ... I'd love to hear your feedback!

um... can anyone here define "WYSIWTFFTWOMG"? What You See Is What The Fuck For The Win Oh My God ... is the closest I can come and it makes no sense.