Comments on WYSIWTF

53 Reader Comments

Back to the Column
  1. 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.

    Copy & paste the code below to embed this comment.
  2. Inline editing is almost as evil as WYSIWYG because people tend to think this content will never be used elsewhere…

    Copy & paste the code below to embed this comment.
  3. 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.

    Copy & paste the code below to embed this comment.
  4. 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 :)

    Copy & paste the code below to embed this comment.
  5. I wish you could see me slow clapping at my desk right now…Thanks for this.

    Copy & paste the code below to embed this comment.
  6. 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?


    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?

    Copy & paste the code below to embed this comment.
  7. 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!

    Copy & paste the code below to embed this comment.
  8. and what about tables. CMS and cms editors seem to ignore tables. But users still need to use tables in content.

    Copy & paste the code below to embed this comment.
  9. Feel free to check out Inkling Habitat ( ! We’re working hard to solve a lot of the pain points you mentioned here.

    Any and all feedback is welcome :)

    Copy & paste the code below to embed this comment.
  10. 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.

    Copy & paste the code below to embed this comment.
  11. 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.

    Copy & paste the code below to embed this comment.
  12. 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”.

    Copy & paste the code below to embed this comment.
  13. 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.


    Copy & paste the code below to embed this comment.
  14. 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.

    Copy & paste the code below to embed this comment.
  15. 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.

    Copy & paste the code below to embed this comment.
  16. While we concern ourselves with separating semantics from content, aren’t we forgetting to look for ideas how we can put semantics into context?

    Copy & paste the code below to embed this comment.
  17. I’d just like to point out another markup language that adds (custom) semantics to text:

    Semantic MediaWiki (SMW) is a free, open-source extension to MediaWiki […] that lets you store and query data within the wiki’s pages.

    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!

    Copy & paste the code below to embed this comment.
  18. 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.

    Copy & paste the code below to embed this comment.
  19. @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.

    Copy & paste the code below to embed this comment.
  20. 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.

    Copy & paste the code below to embed this comment.
  21. 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.

    Copy & paste the code below to embed this comment.
  22. 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…

    Copy & paste the code below to embed this comment.
  23. Karen, your point about the issue that <em> 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.

    Copy & paste the code below to embed this comment.
  24. 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.

    Copy & paste the code below to embed this comment.
  25. I just thought of name for this emerging set of concerns:

    Post-Skeuomorphic Diasporal Content Strategy

    You’re welcome!

    Copy & paste the code below to embed this comment.
  26. 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?

    Copy & paste the code below to embed this comment.
  27. 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 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:, ,, Anyone interested in working on this (and maybe contributing it to Drupal) please connect with me on twitter.

    Copy & paste the code below to embed this comment.
  28. 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 ( 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.

    Copy & paste the code below to embed this comment.
  29. 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.


    Copy & paste the code below to embed this comment.
  30. Check out DITA ( or better yet, weigh in on LightWeight DITA (, 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.

    Copy & paste the code below to embed this comment.
  31. 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.
    (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.

    Copy & paste the code below to embed this comment.
  32. 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?

    Copy & paste the code below to embed this comment.
  33. 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.

    Copy & paste the code below to embed this comment.
  34. 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.

    Copy & paste the code below to embed this comment.
  35. @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.

    Copy & paste the code below to embed this comment.
  36. @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.

    Copy & paste the code below to embed this comment.
  37. 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.


    Copy & paste the code below to embed this comment.
  38. 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; 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?

    Copy & paste the code below to embed this comment.
  39. @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.

    Copy & paste the code below to embed this comment.
  40. May I strongly recommend taking a look at Substance. Michael Aufreiter and his team are doing some amazing work in this space.

    Copy & paste the code below to embed this comment.
  41. Tom, thanks for the link to Substance. That actually is some pretty interesting work.

    Copy & paste the code below to embed this comment.
  42. 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.

    Copy & paste the code below to embed this comment.
  43. 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.

    Copy & paste the code below to embed this comment.
  44. 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).

    Copy & paste the code below to embed this comment.
  45. 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?

    Copy & paste the code below to embed this comment.
  46. WYSIWTF became 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.

    Copy & paste the code below to embed this comment.
  47. 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.

    Copy & paste the code below to embed this comment.
  48. I have to give another plug for ProcessWire (

    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.

    Copy & paste the code below to embed this comment.
  49. Sorry, commenting is closed on this article.