
Wysiwtfftwomg - Isofarro
http://www.markboulton.co.uk/journal/wysiwtfftwomg
======
bcoates
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.

~~~
qznc
I think the point is that "preview" is broken concept too.

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?

~~~
bcoates
All of them? I don't think there's a way around that, including expecting the
people writing your copy to operate in the abstract realm of responsive CSS or
whatever.

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.

~~~
aaronem
I'm not sure I agree on your last point; some of the younger, less print-bound
designers I've worked with have a good understanding of the difference between
presentation and semantics, and have been often enough annoyed by sites which
look just dandy at 1920x1080, but are unusable on a phone, to have a burning
desire not to produce more of the same.

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.

------
DanI-S
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.

~~~
mintplant
Lazarus [1] solves this problem. It auto-saves what you fill into forms, and
allows you to go recover previous versions. You can right-click on any input,
pick a saved copy, and restore.

Firefox: [https://addons.mozilla.org/En-us/firefox/addon/lazarus-
form-...](https://addons.mozilla.org/En-us/firefox/addon/lazarus-form-
recovery/)

Chrome: [https://chrome.google.com/webstore/detail/lazarus-form-
recov...](https://chrome.google.com/webstore/detail/lazarus-form-
recovery/loljledaigphbcpfhfmgopdkppkifgno?hl=en)

Safari: [http://getlazarus.com/download](http://getlazarus.com/download)

~~~
LordIllidan
Doesn't seem to work for WYSIWYG fields in Chrome:

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](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.

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

~~~
ams6110
There is really no more difficulty in learning Markdown than there is
difficulty in learning how to avoid all the baffling, un-undo-able ways that
most rich text boxes can completely stuff up the formatting of your content,
to the point where you simply have to wipe it all out and start over.

~~~
andrewflnr
Objectively, Markdown isn't hard to learn, but people don't really want to
learn anything, they just want to look for the button. Discoverability is, for
most people, an important advantage of GUIs over most interpretation-of-
freeform-text interfaces (like command lines and programming or formatting
languages).

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

~~~
Hemospectrum
> 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.

~~~
Samuel_Michon
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.

~~~
Hemospectrum
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._

------
cabirum
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...](http://en.wikipedia.org/wiki/Help:Table/Introduction_to_tables)

[2]: [https://github.com/adam-p/markdown-here/wiki/Markdown-
Cheats...](https://github.com/adam-p/markdown-here/wiki/Markdown-
Cheatsheet#wiki-tables)

~~~
egeozcan
It doesn't have to be plain-text. It just needs to be structured, _unlike_ a
WYSIWYG editor. Recently I discovered a library called Sir Trevor JS[1] and
thinking about adding a table block to it.

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

~~~
dools
We're working on a way of allowing designers to deploy arbitrarily structured,
editable content with a truly wysiwyg editor:
[http://www.decalcms.com/tour/](http://www.decalcms.com/tour/) what do you
think?

~~~
egeozcan
I've seen and even worked with some examples of this approach earlier. It
works well when you have definitive templates that all the content would fit
but you return to the step 1 when you need a flexible white box for the user
to fill.

~~~
dools
There's actually a way to just include arbitrary HTML (but it's not shown in
the quick initial demo).

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!

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

~~~
Chris_Newton
_We need to segregate data from presentation._

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.

~~~
hyperion2010
Let me rephrase my original statement. We need to segregate data from a single
format/layout.

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.

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

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

------
mwilliamson
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](https://github.com/mwilliamson/mammoth.js)

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

~~~
egeozcan
That's actually not a bad idea at all. Word Plugin API, I assume (I don't even
use Word, let alone making plugins for it), may give you the structure with
the content and all you have to do would be just splitting that information to
put into the right fields.

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

~~~
bithive123
The point is that people have a hard enough time using the existing features
in Word and other WYSIWYG editors which allow for structured documents. Once
an enterprising individual decides to depart from your template using tabs and
spaces you will be helpless again.

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

~~~
guynamedloren
Would love to talk to you about a project I'm working on. It's similar to
Editorially, so as an Editorially user I'd appreciate your thoughts and
feedback on the direction I'm headed. Can I email you?

~~~
shortformblog
Sure — I have an email address listed on my blog,
[http://shortformblog.com/](http://shortformblog.com/). I check it regularly.
Thanks!

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

~~~
andrewingram
Hanging bullets/numerals have nothing to do with markdown, they're a
typographic choice and in my opinion look better than the indented style that
you normally get by default.

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...](http://www.markboulton.co.uk/journal/five-simple-steps-to-better-
typography-part-2)

~~~
ChuckMcM
Thanks for the link, I stand corrected that the OP wants that behavior in his
output. To be honest that is so far out of my expectation for that typographic
choice that I never once considered it a 'desired feature.' So there ya go.

------
8ig8
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.

~~~
yen223
How are kids currently writing their documents? I suspect Microsoft Word will
be with us for a very long time.

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

~~~
dools
This is exactly the problem we're solving at
[http://www.decalcms.com/tour/](http://www.decalcms.com/tour/) what do you
think?

~~~
chmike
It's the fourth comment of you referring your cms tour. This looks like spam
to me.

~~~
dools
Seven, actually.

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

~~~
sjwright
The argument is that Word isn't a discrete application, it's trying to do
everything, and teaching people that they can do anything.

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

~~~
esw
It depends on the user. In my experience, older users (55+) are particularly
incensed when there's any inconsistency between what's visible in the editor
and the outputted page (e.g. "I've been trying for hours, but I can't get the
'e' in this line to line up with the 'h' in the line above it!").

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

~~~
Samuel_Michon
I believe you’re confusing a few different stages in the book creation
process. Also, the submission you’re responding to was about web publishing,
not print.

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.

~~~
curveship
I respect your experience in publishing, but I think it misses my point. It
may be that you work with different genres. My point was that for many
authors, particularly authors on the high end of the fiction market,
appearance _does_ matter to them. These people love books, not just the words
but the physical feel and appearance. They have opinions about the physical
form their book takes. Are they wrong?

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.

~~~
andrewflnr
No one's saying authors shouldn't care about the appearance of their book,
they're saying it should be decoupled from the production of the manuscript.
You can productively worry about the appearance _after_ you get the "nice list
of words, with chapters" aspect of the manuscript down; that's the logical
structure, and, obviously, the hard part. The point is that you don't need a
perfect WYSIWYG editor for the manuscript.

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

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

~~~
smacktoward
In my experience there's no silver bullet way to sell it, but there are some
ways that work depending on who your audience is.

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

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

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

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

~~~
epo
You want some feedback? STFU! This is the fourth time you've pimped your
project on this page. Give it a rest.

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

