Arguing for “separation of content from presentation” implies a neat division between the two. The reality, of course, is that content and form, structure and style, can never be fully separated. Anyone who’s ever written a document and played around to see the impact of different fonts, heading weights, and whitespace on the way the writing flows knows this is true. Anyone who’s ever squinted at HTML code, trying to parse text from tags, knows it too.
On one hand, the division of labor between writing and presentation can be seen at every point in our history. Ancient scribes chiseling stone tablets, medieval monks copying illuminated manuscripts, printers placing movable type—we’ve never assumed that the person who produces the document and the person who comes up with the ideas must be one and the same.
And yet, we know that medium and message are intertwined so tightly, they can’t be easily split apart. Graphic designers rail against the notion that “look and feel” can be painted on at the end of the process, because design influences meaning. The more skilled we are as communicators, the more we realize that the separation of content from presentation is an industrial-age feint, an attempt to standardize and segment tasks that are deeply connected.
Today, we try to enforce the separation of content and form because it’s good for the web. It’s what makes web standards possible. It enables social sharing and flexible reuse of content. It supports accessibility. It’s what will keep us sane as we try to get content onto hundreds of new devices and form factors.
When talking about how best to separate content from presentation, designers and developers tend to focus on front-end code—which makes sense, because that’s what we have the most control over. But, as with so many challenges we have with content on the web, the real issue lies in the tools we give content creators to help them structure, manage, and publish their content. The form that content takes depends as much on CMS as it does on CSS.
How should content management tools guide content creators to focus on meaning and structure? What’s the right amount of control over presentation and styling in the CMS? And how should these tools evolve as we break out of the web page metaphor and publish content flexibly to multiple platforms? Let’s look at three tools that sit at the intersection of content and form.
Preview button#section2
Even the most die-hard structured content editors still like seeing what their work is going to look like. Writers print out documents for editing to give them a different view from what they see on the screen. Bloggers instinctively hit the preview button to look at their work the way a user will see it.
Whoops. Decades of work refining the emulators between desktop publishing programs and laser printers means that writers can feel confident that their document will look virtually identical, regardless of where it’s printed. We’ve carried that assumption over to the web, where it’s categorically untrue. Different browsers render content in their own vexingly special way. Users can change the font size—even add their own custom style sheet. Today, the same document will render differently on desktops, tablets, and mobile devices. The preview button is a lie.
Yet we can’t just throw the baby out with the bathwater. In fact, seeing content in context becomes even more important as our content now lives across devices and platforms. Instead of throwing up our hands and saying “preview is broken,” it’s time to invent a better preview button.
One publishing company I know of has built its own custom preview rendering interface, which shows content producers an example of how each story will appear on the desktop web, the mobile web, and an app. Is it perfect? Far from it. Content will appear in many more contexts than just those three. Is it better than nothing? Absolutely.
WYSIWYG#section3
The desktop publishing revolution ushered in by the Macintosh allowed the user to see a document on screen in a form that closely mirrored the printed version. The toolbar at the top of the screen enabled the user to add formatting—change the font, insert an image, add typographic effects like headings and bullets, and much more.
In an effort to carry over this ease of use to the web, we allow content creators to embed layout and styling information directly into their content. Unfortunately, the code added by content creators can be at odds with the style sheet, and it’s difficult for developers to parse what’s style and what’s substance. When it comes time to put that content on other platforms, we wind up with a muddled mess.
What is the right amount of formatting control to give content creators? That’s a difficult question to answer, because it pierces right to the heart of what’s stylistic and what’s semantic. Even something as simple as adding bold and italic text forces us to ask if we’re really just styling the text, or adding semantic meaning (say, a book title or a warning message.)
Better content modeling can solve some of these problems, encouraging content creators to appropriately “chunk” their text. By banishing blobs of text with formatting embedded and replacing them with chunks of clean, presentation-independent content, we’re building in the distinction between content and form right from the start.
But imagining that each “chunk” of content is a field in the database (with its own input field) rapidly devolves into the absurd. That way lies madness. The real solution isn’t necessarily to “banish blobs,” but to replace the WYSIWYG toolbar with semantic markup. Rather than entering all text into discrete fields, content authors wrap text that describes what it is. Our book title doesn’t need to be a separate field if we can wrap it in the proper tags.
Defining what goes in a field and what goes in a tag requires a tighter collaboration between content authors, CMS architects, and front-end developers. It’s time we started having these conversations.
Inline editing#section4
We’re evolving. Not satisfied to rely just on tools that are vestiges of the desktop publishing era, we’re developing new and innovative ways to mix up content and formatting that are unique to the way the web works. There’s no better example of this than inline editing.
Inline editing allows content creators to directly manipulate content in the interface, with no separation between the editing screen and the display. Medium offers an editing interface that’s identical to the desktop display and in-place editing is being added to Drupal 8 core.
One of the questions I get asked most frequently is “how can I get my content creators to understand why it’s so important to add structure and metadata to their content?” This, I believe, is one of the fundamental challenges we’re facing on the web, particularly as we adapt to a multi-channel future. Inline editing encourages content creators to focus on the visual presentation of the desktop interface. Just at the moment when we need content creators to think about the underlying structure, we’re investing in tools that obscure the “connective tissue.”
Jeff Eaton sums up this problem nicely in a post called Inline Editing and the Cost of Leaky Abstractions:
The editing interfaces we offer to users send them important messages, whether we intend it or not. They are affordances, like knobs on doors and buttons on telephones. If the primary editing interface we present is also the visual design seen by site visitors, we are saying: “This page is what you manage! The things you see on it are the true form of your content.”
The best solution isn’t to build tools that hide that complexity from the user, that make them think that the styling they’re adding to the desktop site is the “real” version of the content. Instead, our goal should be to communicate the appropriate complexity of the interface, and help guide users to add the right structure and styling.
The era of “desktop publishing” is over. Same goes for the era where we privilege the desktop web interface above all others. The tools we create to manage our content are vestiges of the desktop publishing revolution, where we tried to enable as much direct manipulation of content as possible. In a world where we have infinite possible outputs for our content, it’s time to move beyond tools that rely on visual styling to convey semantic meaning. If we want true separation of content from form, it has to start in the CMS.
One acronym I’ve come across recently is WYSIWYM (What you see is what you mean) – this works great with HTML or Markdown as it helps explain to the author that the way their text looks is directly connected to how they describe it.
Inline editing is almost as evil as WYSIWYG because people tend to think this content will never be used elsewhere…
This is a more than timely discussion. The era of desktop publishing may be over but it is dying with a fight. We use the WYSIWYM acronym mentioned by Stewart. We use a very comprehensive set of controlled selectors to make sure content can be easily reused and processed for just about everything. Then multiple design profiles can be used to make it look different for print, e-books, static sites or whatever. We call it FoundationXHTML because that’s what it is and it is a different use from a Web approach.
I would argue “semantic” markup. 2013 content needs structure, semantics, processing, presentation, styling and metadata tagging to make it really widely useful. XHTML5 is structure which can have all these other properties applied reasonably easily with a few tools.
This article couldn’t have come at a better time for me!
We’re exploring an interesting problem here at GatherContent (content production tool) surrounding the separation of content from presentation. The problem is keeping people from both ends of the content-creation spectrum happy.
You’ve got the content/web folks who couldn’t think of anything worse than a fully featured WYSIWYG editor, opposed to “non-technical” users who cling to “word-like” writing environments.
We were heavily considering switching to Markdown but after talking to our customers it was evident we’d lose an arse-tonne of value. The main issue was the lack of time/will to educate the colleagues and clients who are producing the core of the content, despite the apparent simplicity of Markdown syntax.
So, we’re now exploring an approach (for the lack of a better way of describing it) of… What You Get Is What You Need.
A limited WYSIWYG editor (bear with me) with very strict HTML mark-up (similar to what the HTML output of Markdown is), whilst still offering the visual cues of a more traditional writing environment.
We’re solving the semantics by enabling authors to tag content elements (“chunks”) to further describe the content within, so when retrieving content via the API you have more flexibility to get the appropriate content for the job.
I’d love some feedback on this… approach 🙂
I wish you could see me slow clapping at my desk right now…Thanks for this.
What do you make of “multi-device preview” approaches like Sitecore’s, which attempts to show the author how the content will render in a specific set of devices?
(http://www.sitecore.net/Community/Technical-Blogs/John-West-Sitecore-Blog/Posts/2012/11/Sitecore-ASPNET-CMS-6-6-Features-Device-Simulation.aspx)
On the one hand, this approach breaks us out of the “one view” model, in which preview sets the expectation that what I wrote/designed will be seen exactly the same by all users; on the other they still set the expectation that users will see can be known (and imply that it can and should be controlled).
Is it better to abandon the notion of preview altogether, or describe it as “partial preview” or something?
If the “one giant blob” WYSIWYG field is the anti-pattern, but the “one field in the DB for everything which might someday be a semantic chunk” is also madness, what does the middle ground actually look like?
Most mature CMS platforms will let the implementing team create complex content types – but as the pendulum swings back toward structured content there’s a risk of higher complexity for authors again.
Do we need to revisit the common assumption that the user entering and editing content directly in the web interface of the CMS is the author? What if we had simpler author submission flows then had that content “marked up” by a newly re-intermediated role of CMS editor, like typesetters and page layout folks in the old world, but more focused on semantics – content markup folks? Semantic enhancing teams?
James, I have zero problem with a very limited WYSIWYG that offers only the most basic semantic HTML markup: headings, ordered and numbered lists, bold and italic, etc. From an ease-of-use perspective, that makes more sense for content creators, and there should be no difficultly in converting and parsing those tags.
Even that, however, does raise issues of whether the tag is used for styling or semantics. Why bother trying to communicate the difference between italics and emphasis to content creators, if every major browser renders as italics? Well, what happens when speech interfaces are mainstream, and emphasis has a different vocal cue? A lot of shouty book titles, perhaps.
I think the *really* interesting future is figuring out what should be represented with a field and what should be represented with custom markup in the editor that define what something is.
I storified a little rant from @eaton on this topic: http://storify.com/karenmcgrane/wysiwyg-as-editor-for-rich-data-types
The link to the Medium editing interface is giving me a 404. Anyone else seeing that? I’d love to see what it looks like!
John, I respect the need to preview and see work in context. Especially as we’re trying to get content creators to understand how structured content for multi-channel publishing works, showing them will go a long way. We’ll never be able to show everything EXACTLY as it will look, but I think it’s okay to provide some training wheels. Showing a few possible options for the display really helps.
I think the discussion of what’s a separate field and what can be a custom semantic tag wrapping text in a blob is one of the most interesting questions we can answer. I think that’s the middle path between too much fielding and blobs with presentation markup embedded.
For large enterprise organizations, I think a very strong organizational model is to have a core editorial team that sits in marketing or UX, and these are the only people who have the keys to publishing to CMS. I think many orgs went overboard on decentralized content publishing. Having a core team of expert users means you get people who know the tools and can also enforce good writing practices. (This model probably won’t work for highly decentralized orgs like government or higher ed, but for banks, healthcare, and the like, I think it’s a compelling option.)
Broken link to Medium is fixed!
and what about tables. CMS and cms editors seem to ignore tables. But users still need to use tables in content.
Feel free to check out Inkling Habitat (www.inkling.com/habitat) ! We’re working hard to solve a lot of the pain points you mentioned here.
Any and all feedback is welcome 🙂
I’m a front end (and some back-end) developer and I’ve been recently introduced to the world of content strategy by way of a webinar and book by Sara Wachter-Boettcher and I find it fascinating.
I’ve found many resources on the subject of content strategy, blobs vs. chunks, etc, but have not found much on the technical implementation side. Most of the content on this subject seems to be about how to determine content types and models.
My question then, are there resources for the person or team that will actually be implementing the content strategist’s strategy?
I’ve not had much luck finding resources on this side of the equation. Perhaps I’m googling the wrong phrases. I’ve found conceptual overviews such as the articles on NPR’s COPE, but nothing of a more practical nature, such as current solutions or strategies.
Great article here, as always from you Karen,
It’s really interesting to read this as I am involved in the process of redesigning and rebuilding the UI of an open source CMS (eZ Publish) that echoes really well with what you call “adaptive content”.
As often, it seems the truth lies in balance and compromise:
– Time for “page based” CMS editing is over (actually it has never been at eZ) but more than ever it is through the page that you access content. It’s all about context then.
– Wysiwyg is almost dead but we keep it as it is a strong mark for end-users to find their way. We simply keep the good habit of forbidding full-freedom in the wysiwyg and using tagging.
– While multichannel and multi-screens is more than ever pushing for real separation between C & P, preview is paradoxically more than ever requested by users who, more and more, needs to be reinsured their content will look good when delivered. We need to provide context aware preview, taking into account not only the device but other elements of context like the site you are on (as content can live on different sites), the screen, the location… I am still thinking about how to preview retina display on standard devices 😉
And yes, not new, the big question often is “what should we put as a field and what should be tagged in the rich text” and I guess here the only way is to give Information Architects the choice as one size doesn’t fit all.
Please Karen keep feeding us with good content like this, it makes our work easier and our life better! Congrats for this paper.
Shawn, I won’t put anybody on the spot here, but I know of three people who are working on books (or at least talking about writing books) on that very subject. I do think it varies by CMS.
To achieve this goal a CMS has to be completely flexible relating custom fields and think of pages as content holders and not as the typical page that is rendered in the browser. Have a look at my CMS of choice, ProcessWire. In PW, each “page” lives in a unique Url but can be anything you want it to be (only content, json, xml, javascript… whatever), and the content can be easily passed to other “pages”.
In my own opinion, the best way to separate content from presentation is to use lightweight markup languages like markdown, textile, reStructuredText, and so on.
Most of theme are easy to learn.
They can be converted to valid html, open documents, e-books, xml and pdf using templates where all the styling and processing reside.
It’s especially frustrating for us structured content fans when WYSIWYG and inline editing are presented as *the* solutions to “improving the author experience” in the CMS. Drupal, I’m looking at you!*
Then there’s the “enterprise” CMS that proudly promotes its Office-style ribbon interface as a usability feature. (The “better the devil you know” principle I suppose.)
Of course, content strategists including Karen herself have been going on for years about improving the author experience. So, on the one hand, it’s great that CMS people are at least paying lip service to content authors. But on the other hand, that wasn’t quite what we meant.
*In fairness, there’s a lot of great stuff going in Drupal as well.
I guess I’m also a fan of using structured content and forms where it makes sense, and for larger bodies of text, using Markdown. James I’d be curious to know what your company found in terms of customers aversion to Markdown. I’ve not done user tests with it yet, but I guess I was optimistic based on some family members using it.
I think the way Github adapted it to tag specific blocks of code with their (“`ruby …. “`) syntax could be used to tag other things as well, but again – this is all more stuff for the user to learn, and suddenly it’s more complicated and it has become markup, not markdown.
A thought provoking column either way, thank you for sharing.
While we concern ourselves with separating semantics from content, aren’t we forgetting to look for ideas how we can put semantics into context?
I’d just like to point out another markup language that adds (custom) semantics to text:
http://semantic-mediawiki.org/wiki/Semantic_MediaWiki
In general it seems the wiki syntax is often forgotten in the discussion.
Nevertheless it’s another syntax that needs to be learned.
Btw: Great article title!
Coming from a wiki environment we are constantly bouncing between clients demanding WYSIWYG (at least in the beginning) and users that prefer writing content in wiki markup using a “WIKIWYG” editor. These kind of editors help lowering the learning curve for different markup dialects which Markdown is one of them.
There are two killer-features remaining in WYSIWYG: image previews and table editing. But that’s almost it. Seriously. None of the other WYSIWYG features – fonts, colors, spacing – should be of concern while writing. Instead they are much more a distraction. People constantly fiddle with these things, most of the time not for the better.
So what should good editing tools be like? They should support the process of writing. This of course should include gathering meta data along the way, as well as easing the handling of additional material like images, but also searching for related material automatically, presumably based on the meta data already attached to the document being produced. That’s of much more help than neat color pickers.
The situation of a writer comes with quite different needs compared to the reading situation. Writing is a much more complex process. The requirements for the reading situation are, well, that the text is easy to read and understand. As reading and writing are so different the case for WYSIWYG and inline editing are pretty weak in my eyes, despite their sexiness.
Another quite important point not mentioned yet is constraint editing. These editors only allow to produce well-formed documents based on a predefined schema. There are definitely strong pros in this as the result will be (semantically) marked up documents that can be processed automatically while presenting content in different contexts. There are two problems with constraint editors: (1) they are expensive to set up: there are only a few market leaders that have products with good-enough editors in place. Once settled with a product, they are expensive to deploy. Ever used DITA? (2) constraint editors they are complex to use: the task to guide the writer comes with all sorts of usability problems and interface clutter.
@Jason The main issue we found our customers faced was the time it takes to educate, and introducing a new concept to people who really aren’t very excited about producing “website content” anyway.
Obviously it’s dependant on the organisation, and each will have their quirks, but for those managing larger content projects with lots of subject matter experts (think Engineer at Oil Company) have a tough enough time as it is.
Personally I like Markdown, and I love the way Editorially have implemented it within their writing experience. Markdown is perfect for someone like me who wants to write a blog post or something very singular but I don’t think it’s quite ready for large scale content projects.
Perhaps I’m wrong- but I do hope that one day Markdown, or something similar takes off.
Michael, I really enjoyed your comment and agree with all your points. Just to build on something you said, I agree that fooling around with fonts and colors is a waste of time for most writing, and especially as a feature in the CMS. The options given to authors should only be what they actually need, which is limited to semantic markup tags. Whether we implement that capability as a toolbar or as Markdown is really not the issue.
The real issue is, as Michael points out, is supporting more complex authoring tasks like finding and attaching related material or images, adding appropriate metadata, and creating more complex document structures like tables and charts. Those challenges are what makes authoring in the CMS different from Microsoft Word. Making those interfaces more usable is the problem we should be wrestling with, here in the 21st century.
This is a problem that extends beyond the classic CMS situation. For example, Doctors today are tasked with authoring documents in their EHRs using similar tools as content managers use on classic CMSes.
When a doctor authors a visit note, they don’t realize that this document is going to go across multiple channels. It will be possibly printed, faxed, or even put on a mobile portal. I have heard doctors demand WYSIWIG features to be able to control the output of their note. They consider this note their brand. Especially when a specialist is called-in for a consult and so they would like it to be “just so” because it will be read by a colleague.
The doctor authors this note to be read by a human. But really, a doctor’s note is full of semantically taggable information like test results, diagnosis, treatment plans, and other things like that. Those things could be re-interpreted and reused in many other channels.
To accomodate that, some systems forgo the blob approach and go all chunks where everything is semantic. Most doctors hate this approach because they care about the quality of the narrative that gets produced. The narrative produced by those systems tend to sound like robo-doctor.
On the other hand, systems that hide this complexity tend to fail as well because there is no incentive for the doctor to go beyond the actual blob. There is no incentive for them to tag the data after the fact to give it semantic meaning.
Designing a balanced approach to authoring semantically rich content is needed there as well.
We spend a lot of time thinking about this for Perch, as content being stored based on what it is by way of a template system was a core element of Perch. We ship the product without a WYSIWYG and encourage people to write their own structured templates, and a lot of people do. By making the templating system easy we hope to encourage front-end devs to really think about how content should be represented and help content editors to write great content that can be reused.
However, it is a real battle to get a lot of people out of the mindset of thinking that their CMS should be like Word. We’ve had to offer WYSIWYG plugins as there are a lot of our users who will not write templates and just want to give users a big textarea and let them decide what goes in it. I’m sure a lot of effort on the part of CMS vendors goes into creating better WYSIWYG-like environments and inline in-context editors (which again tie the content to one particular rendering) due to needing to meet customer demand. We’ve tried to provide for that demand without it taking our focus by creating a plugin system for these third party editors.
Tables, other than the very simplest of structures, are a hard problem to solve – especially if you care (as we do) about the level of accessibility of the CMS. Inline images and media are hard, especially if you want to cope with multiple resolutions for RWD/retina displays. It’s in these places where people decide to just throw in a WYSIWYG editor to get the job done – even where they understand the use of structured content. These are things we are trying to solve in our way for our system but I’m very happy to see other people thinking along the same lines.
The same happens with Microsoft Word in companies. I’m a Graphic Designer and always had lots of trouble to format documents written previously by the content people in the company I worked in, because they didn’t used styles at all, and were formatting the text while writing it. I remembered that I decided to learn Word, just as I learned inDesign and Illustrator before, and was very surprised how powerful it is when used right. I honestly thought that after this learning I would be able to teach my co-workers to use it in the right way and we would all have a much better time with our documents (them, writing, and me formatting). It wasn’t like this, and when I left the company, the content people were still handing me their documents with bold, manually sized, titles, even after I taught them how to define styles, and told them that I would be the one deciding these kind of details, and they only had to worry about the writing. I don’t think this is a lost cause, but it is undoubtedly, a difficult one…
Karen, your point about the issue that tags may raise for screen readers one day is very helpful. Are there other examples that come to mind of where WYSIWYG behaviors are likely to cause accessibility issues (either now or down the road a bit)? In working with higher ed clients my team has found that their highly devolved content ownership models necessitate some level of WYSIWYG functionality for CMS users (the skill level of 300-500 different editors varies wildly, as you can imagine), but that creates tension with their desire to ensure WCAG compliance.
Of course, no matter how you look at it, no matter how advanced an editor you’re providing the customer, there will always be content editors who find it neccesary to copy and paste word documents into an editor (and report a bug if it doesn’t work).
With such stupidity in mind, how can we ever make an editor truly WYSIWYG if the user is pasting a friggin’ word document? Now, you can of course educate the customer a little bit, but they’ll keep doing it, so long as they’ve got content readily available in their word processor of choice. Saying “you’re doing it wrong!” does not work indefinately.
We need some rediculously awesome WYSIWYG editor that provides just the right amount of control, and can cope with stupidity.
I just thought of name for this emerging set of concerns:
Post-Skeuomorphic Diasporal Content Strategy
You’re welcome!
Assuming you’ve done the herculean task of examining your content and developing content types and models, then I believe it should be entirely possible to build a WYSIWYG environment for content authors.
Here’s what I mean: take the idea of a toolbar filled with semantic markup buttons, which Rick Yagodich talked about on twitter and in email. These semantic markup buttons are relevant to your business. They represent the “chunks”, the book title, the author, the address, the ingredients, hed, lede, nut graf, etc. You can extrapolate further what that means for you and your organization.
Now I offer, that as an organization, your designers have already designed what that content looks like on the desktop web, the mobile web, your app, etc (whatever platforms you’re currently on). Although this idea of content strategy has its eye on the future, we live in the present, so we’re designing for the present (because that’s all we know for now) and content strategizing for the future.
So, we have the formatting and design of our current platforms, this should be enough to provide the content author with a preview for how it will look, on the current platforms, in the current way it is being used. I don’t think the content author even cares what it looks like on someone’s refrigerator in 2018, and it doesn’t matter because you’re Team Chunk (and now have semantically marked up content), so we present that preview according to the platforms we use now.
And further, I think the previews can be smart, dynamic and interactive. You should be able to turn off or on the various chunks, and the preview can react accordingly.
Does any of this strike a chord, or am I playing to an empty bar?
Hi Karen,
Thanks for the mention of our edit-in-place module for Drupal 8 core.
I’m really excited that you bring this topic up. I believe that WYSIWYM will become central in this problem space *if* it connects to machine-learning APIs and libraries like schema.org and Apache OpenNLP (natural language Parsing) *and* it’s effortless and usable (I’m workin on it).
When you say “Imagining that each “chunk” of content is a field in the database (with its own input field) rapidly devolves into the absurd.” you’re only half right. Yes every tag—maybe even every word—can be semantic data in the database, but there’s only one input field; the WYSIWYM. But let’s go even further. Essentially *every* formatting decision a user makes in a wysiwyg potentially has both visual and semantic meaning, not just the obvious formatting like lists and headings. If I make a single word a different color chances are that’s not random and may be the equivalent of an em tag, if it’s red it may be a warning, if it’s bold, red and all caps, you can bet your a** it’s a warning! If a
is bigger than everything else on the page, well, it’s really a heading isn’t it? The WYSIWYM should know that.
There’s a metric ton of work to do to make something like this happen but it’s absolutely possible and, in fact, it’s already underway: http://aksw.org/Projects/RDFaCE.html, http://www.wymeditor.org/ , http://apps.carleton.edu/opensource/loki/, Anyone interested in working on this (and maybe contributing it to Drupal) please connect with me on twitter.
replace the WYSIWYG toolbar with semantic markup
This has been done quite a lot for a long time, with mixed success (LyX is a good example, customised XML editors like Xopus are another). Unfortunately, getting authors to express their semantics can be hard: we have been successfully gulled by 30 years of wordprocessing to think that if it looks pretty, it must be right. In the process, many people really do now believe that “the person who produces the document and the person who comes up with the ideas must be one and the same”.
I’m about 90% of the way through my thesis on the interfaces to editing structured text (http://wiki.ucc.ie/structed/) and thank you for expressing the problem so succinctly. Editor interface design is still in sore need of adaptation to the way people write and think, rather than the other way round.
my word. i’ve been waiting a very, very long time
to read something this intelligent on “a list apart”.
looking at scans of old books (project gutenberg),
i learned that the best way to ascertain structure
is to examine presentation, since the _purpose_
of presentation is to communicate that structure.
in other words, the two were inextricably mixed…
so this insistence that we treat them as separate
— heck, a notion that we _could_ do such a thing —
has always seemed to be ridiculous to an extreme.
even though there are some benefits — but, chiefly,
those happen to be a matter of mere convenience —
the fact that it is fundamentally wrong is troubling.
-bowerbird
Check out DITA (dita.xml.org) or better yet, weigh in on LightWeight DITA (http://www.linkedin.com/groups/Lightweight-DITA-4943862), which is still being developed. It’s not your tools, it’s your strategy. Then, OK, it’s your tools. Any DITA-compliant CMS will let you 1) add all the markup and metadata you need, 2) preview/publish to multiple outputs quickly, and 3) do about a thousand other awesome things, like get direct feedback from users, send draft content for collaborative review intelligently, manage translations and localizations, etc. Even if DITA doesn’t fit your model, XML is the language you need to leverage the heck out of your content and only mess around with design in a central, well-managed way. Oh right, and it’s an open standard, which opens up the door for all sorts of opportunities in tool support (standardization, yay!) or even share or OEM content to other divisions, companies, partners.
As a long time developer in the WYSIWYG area (TinyMCE) this isn’t really a new discussion.
The fact remains, the users expect a WYSIWYG editor to work like your common Word/Office software, that’s where the base of the problem lies. More often than not, developers will have more success implementing a proper WYSIWYG experience if they configure it really strict.
We have seen good implementations, but to be honest, most of the implementations being made into various CMSes tend to be really poor quality, It is like they create the CMS, and last second they throw in the WYSIWYG editor, then hope for the best.
There is all this other talk of using something OTHER than HTML for markup… I ask why, your just blaming the wrong part and creating more work. HTML is a good markup language obviously, however what you can do within a WYSIWYG area is entirely up to the implementation and nothing really todo with the way you markup your code.
And as a WYSIWYG editor developer, do I really have to create the whole CMS for you?
We give you this powerful engine, but you don’t even bother connecting all the cables.
We actually did make CMS systems once, this is a demo from I think 2009 (video made more recently). Shows a fairly simple CMS, context based inline editing using TinyMCE 3.x as its engine, areas are edited separately, but saved together.
http://www.screencast.com/t/eKyUhygzJlxQ
(No this CMS is not on the market and never will be)
The examples of systems using the engine in a proper way like this is really rare, way to rare, but we hope to change this in the near future.
Great article and I’m fascinated with this space. My earlier content experiences were planning, developing and designing for museum exhibits—which often mean a “seamless” interplay of text, word, objects, cases, and visitor flows. I often created “semantic spreadsheets” for curators to write to instead of documents created in Word. And then the internet happened and (thank god) intentional CMS.
I’m wondering as we examine new ways of organizing our creation of of meaning if there is a place to see what CMS and markup systems are being used right now or in development? The end results of these systems clearly are all over the place, but the input system is often hidden and/or internal focused. Is there a gallery of CMS and similar out there?
One of the (many) great things about responsive design is that you can see what a site will look like on various screen sizes simply by scaling your browser window’s width. When we want to preview a blog post or a new page on our sites, we hit our preview button and start scaling.
Granted, this only works for screen size changes that occur, not platform specific changes, but it does give a good sense of what a page will look like at different sizes.
I think the web has been hijacked by “designers” for too long. Good content doesn’t need much graphic design. It needs to be clearly written with a readable font. This is why I like Zeldman’s blog: little graphic content, just clear well written text. I am not saying no effort went into that design. But it was an effort aimed at minimising visual design distractions.
I think I am not the only one either. It’s not for nothing that services such as Flipboard are so popular. Readers are fed up with all the graphic design getting in the way of content.
@Robin, you are complaining about bad graphic design, good graphic design stays out of the way. If it wasn’t for good graphic design, Zeldman’s blog wouldn’t be that nice as you say, it would just be one among others. Anyway, separation from content and design only means that the content is not dependent on design, doesn’t mean that you shouldn’t design each of the supports where that content will appear.
@diogo: I simply don’t agree with that. Good content is good content. And remains good content in black and white. Newspapers, novels and most journals do just fine with none or almost no graphic design (or even design beyond choice of font). For sure a brochure site who’s purpose is marketing, needs to be designed by a professional. But information is information and can be presented in black and white and often that is actually it’s most useable, accessible and readable form. The design part on the web should be about how to get to that information and unfortunately in most cases the design actually gets in the way of this.
I would love to live in a WYSIWYM world, but many large orgs aren’t there yet. Am even seeing Adobe make inroads with PDF-only web experiences — forget that responsive; we need control! Couple that instinct with proclamations of the end of RSS and I’m concerned that for every system struggling for semantic balance between content and design, there’s a backlash toward a controlled environment.
The key is to help CMS purchasers and admin interface designers/devs understand the tradeoffs — and use concrete data about content reach to motivate the admin users.
Thanks for a clarifying piece.
One of the many reasons I’m grateful for this article is what I think is the sentiment from the following paragraph:
“And yet, we know that medium and message are intertwined so tightly, they can’t be easily split apart. Graphic designers rail against the notion that “look and feel” can be painted on at the end of the process, because design influences meaning. The more skilled we are as communicators, the more we realize that the separation of content from presentation is an industrial-age feint, an attempt to standardize and segment tasks that are deeply connected.”
My interpretation is that the pursuit of an adaptive content strategy shouldn’t ignore the role of visual design and feel in delivering the most appropriate and impactful user experience, as described during Margot Bloomstein’s discussion of message architecture in her book, Content Strategy at Work.
I understand the need and subscribe to the school that applies content modeling; structural, administrative, and descriptive metadata; markdown; NPR.org-COPE-like strategies; and related tactics to create content that enables a CMS to effectively display the appropriate content on a variety of screen sizes.
But if my interpretation is correct, does the role of integrating visual design into the adaptive content development process need greater prominence during these discussions?
@Robin, I’m sorry but I think your idea of what is graphic design is plain wrong. There is much more graphic design on a good newspaper than on any small brochure website. The choice of the font is already a graphic design decision.
May I strongly recommend taking a look at Substance. Michael Aufreiter and his team are doing some amazing work in this space.
Tom, thanks for the link to Substance. That actually is some pretty interesting work.
THIS: “For large enterprise organizations, I think a very strong organizational model is to have a core editorial team that sits in marketing or UX, and these are the only people who have the keys to publishing to CMS … Having a core team of expert users means you get people who know the tools and can also enforce good writing practices.”
To me, organizational and training methods can address a great many of the issues outlined in this article. Create a team that mans the publication gate and that has been trained in what tags to use and when, and you’re a long way toward a more semantic and scalable content-production process.
Perry- I completely agree. WYSIWYM is the ideal solution, but it is like… like… OK, I couldn’t come up with an analogy that wouldn’t possibly offend someone.
Speaking from experience, having attempted to launch a semantic authoring experience, I am still getting hit with pebbles. The approach we are making now is a compromise that allows for both a pure semantic editing experience or one that allows you to style at will. Essentially, give the developers and designers the power to make the decision of what is best for their scenario.
As Karen pointed out, dealing with attached content could be hard. But when you are considering everything as a document it could because a little bit easier :
For example, an image is a document, with metadata embedded within itself (exif, authorship, licence, etc…). Using a template, you will be able to extract those embedded datas to generate some kind of image box with the resized image and the author name in the box footer.
A spreadsheet (csv, ods, xlsx) is a document that could be used as a data source to generate svg charts using data processors (templates).
A video is a document with embedded metadata, that can be transcoded and embedded into a flash player or in a html5 video tag.
A tweet is an external document (represented by an url), that can be rendered using a oEmbed endpoint.
So, as of text editing, you are separating content from presentation. Maintaining relations between documents can be done in many ways (xml document describing relations or a good old databases).
I find the debate about “fields in a database” vs. “semantic markup” very interesting. I agree that fields become a mess if there are too many you don’t want to fill out anyway. But I find it hard to believe that it’s possible to come up with a GUI that will let most content creators easily mark up their texts with semantic tags, especially if there are so many different tags that you couldn’t better solve it with a field for each value.
So as long as you want a seizable chunk of people to enter content into the system (as opposed to one or two expert data modellers), I cannot see how markup is a better solution than fields. Or am I missing something?
WYSIWTF became WYSIFTW: http://rasmusskjoldan.com/post/58364140673/wysiftw – upon 3 months of meditating over this article. Can’t say how tremendously your article inspired me and the team I work on. Thx again.
That is why for the past 10 years Magnolia CMS has combined these approaches by giving you an agile repository that allows data structures to be changed on the fly, a UI that is rendered automatically based on the data structures you define, and thus providing you with component based templates that allow you to edit content anywhere between one field per data item (one extreme) to one giant rich text blob (the other extreme). Our default sits right in the middle – separate fields for semantically meaningful entities like the headline, abstract of an article, images (with meta data) etc. while the main content are blobs of rich text.
Magnolia combines that flexibility with a nice customizable preview mode to view the result in the channel of your liking.
I have to give another plug for ProcessWire (http://www.processwire.com).
Karen, if you haven’t seen ProcessWire before, it is basically everything you’ve talked about, already implemented in a CMS! All fields are custom fields and allow you to “chunk” out your content into individual bits and output them (separate from any predefined markup) however you’d like on the page. The API allows you to access and manipulate your content similar to how jQuery works with the DOM.
It’s a great framework for basically designing a individualized content “system” specific to each website.