Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

When Editors Design – Controlling Presentation In Structured Content

Thanks to the skyrocketing popularity of mobile devices, a new generation of designers and CMS developers has found the religion of Structured Content. Once the domain of semantic markup purists and information architects, structured content models are at the heart of most multi-channel and multi-device Web projects.

When Editors Design – Controlling Presentation In Structured Content

At Lullabot1, we often work with media, publishing and enterprise clients. Those businesses produce so much content and manage so many publishing channels that keeping presentation and design-specific markup out of their content is an absolute requirement. Unfortunately, this doesn’t mean that editors and writers are content with rigid, predictable designs for the material they publish.

Further Reading on SmashingMag:

This challenging requirement — providing editors and writers with more control over the presentation of their content — is where many well-intentioned content models break down. In this article, I’ll share five techniques we’ve used on recent projects to solve these problems. These approaches work particularly well in Drupal but can be used any time that editors need more control over design.

The Easy (But Problematic) Answers Link

Sadly, a common response in projects on a deadline is to give up on well-structured, reusable content. If the editors want control, let them jam HTML blobs into their stories — they can sort out the details!

To avoid that chaos, some teams go to the opposite extreme. They pile dozens of custom fields onto each content type to capture every possible presentation option, or they give editors a menu of carefully tailored visual templates to choose from for each post. For indexes and landing pages, these teams often build visual layout tools to manage the position and visual style of each post, duplicating familiar page-layout mechanisms.

Both of these extremes can make cross-channel reuse more difficult because they all treat design-dependent information as an integral part of the content. In addition, they often confuse content creators with monstrously complicated input forms, and they force writers and editors to play the role of visual designers. This last point is a big one for fast-moving news organizations: Every minute an editor spends managing presentational tweaks is one they can’t spend on critical stories.

Principles That Work Link

Working with our clients and talking to other experts, we’ve identified a handful of useful tactics that will take the edge off these problems. They won’t solve every problem, but they address these issues without crippling editorial control or compromising our structured-content ideals.

Use Grouping and Priority, Not Manual Layout Link

When we started talking to the editorial team at a major news website, we learned that they wanted to control where articles appeared on the home page — and all of the website’s topical landing pages as well. When we dug deeper and presented simple prototypes, however, we discovered that they meant something different. What the editors really needed were ways to prioritize and organize content on the home page. On their old website, direct manipulation of each page’s layout was the only tool they had, and they were afraid to lose it.

Instead of building complex layout tools or tossing them into a tangle of raw HTML, we built three complementary tools: a simple “Priority” field for each article, several sets of issue- and section-related tags to organize content, and a set of reusable queues, such as “Breaking news” and “Front-page slideshow.” This allowed writers and editors to make simple decisions about each article, like setting the priority of a post to “Major news” or assigning it to the “Politics” section. Editors were given permission to manage the special-purposes queues.

The website draws on these different collections in a variety of ways. News tickers can display headlines of breaking stories across the top of every page, the home page can divide news by issue, and topical landing pages can display the most important stories first. On timeline-oriented archive pages, the “Priority” field can be used to emphasize rather than reorder important articles. All of the results are based on simple filtering and sorting rules, and editors are given control of the “levers” that drive those designs, but they never interact directly with the layout.

The Nodequeue module for Drupal lets editors control multiple curated lists of content for use on complex landing pages. (Large view7)

The advantage of this arm’s-length approach to editorial control is subtle but important. Editorial choices about priority and purpose can carry meaning even when the stories aren’t featured on the home page. Responsive designs can easily translate these collections to vertically stacked layouts, and dedicated mobile apps can push alerts on breaking stories to users. Even when new designs eliminate or add new page regions, the meaningful data in each article will still retain its value.

Capture Emphasis Rather Than Appearance Link

This same design team wanted to keep the website fresh by providing several templates for each type of article. Naturally, the editors wanted to choose the precise design template used for each post. Giving them a drop-down menu to switch between templates was easy with our preferred CMS, but the list of choices only made sense for the desktop design. Tightly coupling that design choice to each article raised some troubling issues: Content feeds for partners and the client’s own mobile apps would be using completely different visual designs. Would the layout choices made by editors be respected there?

The solution was simpler than we expected. We presented the editors with a simple drop-down list, which, instead of offering a selection of templates, gives them a choice of article elements to prioritize. Stories with a particularly dramatic visual component might receive the “Image” or “Video” emphasis, lightweight stories meant to spark discussion would get the “Community” emphasis, and so on.

A simple content type that gives editors a choice of fields to emphasize. (Large view9)

Why does this distinction matter? First, it becomes much easier to preserve emphasis when the content moves from one publication channel to the next. Custom-tailored HTML can be generated when the story is sent via email; simple CSS rules can be used to vary the article’s appearance in a responsive Web design; and a content syndication API passes along the emphasis information without assumption. In addition, emphasis will evolve more gracefully than explicit layout decisions. As the primary website’s appearance changes (and visual templates come and go), designers can decide how to best communicate the emphasis that the editors have chosen.

Use Embedding Codes to Complement Chunky Fields Link

Life gets pretty complicated when videos, slideshows, dynamic widgets and other complex media are used in a piece of content. If the precise position of these embedded elements isn’t important, then we use custom fields to indicate the fact that they’re related to the article, and let design templates handle the rest. Editors enter the key information that’s needed (the URL of a YouTube video and the desired size, for example, or the unique ID of a related piece of content). Then, theming and templating functions control how the custom fields are displayed.

In a recent corporate intranet project, however, that relationship approach wasn’t enough. The company’s HR team needed to embed rich media and widgets, such as insurance calculators, into policy documents for their employees. These embedded elements were part of the narrative flow of the articles and couldn’t simply be listed as “Related resources.”

Rather than throwing up our hands and letting them paste chunks of raw HTML, we used custom placeholder tags, like [slideshow:2], inside the body copy. When the content is displayed, output filters replace those placeholders with the rich content. Content editors never have to deal with the complexities of iframe-based embedding codes or third-party JavaScript snippets, and changes to the design or CMS platform become much easier. When those complex widgets inevitably change, the placeholders in each article remain the same; only the centralized code for replacing them needs to be updated.

Shortcodes and placeholders can be used to embed rich media without manual markup. (Large view11)

In WordPress, this style of placeholder replacement can be implemented using custom shortcodes12. Smashing Magazine covered this approach13 last year, and the Post Snippets14 plugin allows you to set them up without writing custom code. In Drupal, a number of modules, including Token Insert Entity15 and Custom Tokens16, do the same thing.

Put the WYSIWYG Editor on a Diet Link

WYSIWYG editors are popular, with good reason. They simplify editing, prevent most simple HTML errors and give authors a quick idea of how text will look when published. In a world of multi-channel publishing and complex designs, though, WYSIWYG editors carry significant drawbacks. They work fine for simple markup, such as emphasis, block quotes and bullet lists, and they help with attribute-rich elements such as images. However, they often add complexity when editors have to input specific structured HTML to match a website’s design.

On the corporate intranet mentioned earlier, content editors faced this problem in a big way. Common article elements such as call-out warnings and captioned images were too complex for the WYSIWYG editor’s built-in array of buttons and styles. Conscientious editors tried to duplicate the precise markup used by the website’s CSS but often made errors. Others gave up and tried to duplicate the appearance of those styles with the WYSIWYG editor’s table, font-color and image-embedding tools.

The underlying problem is simple: Most WYSIWYG tools are configured as training wheels for HTML. What most content editors really need are shortcuts for the semantic markup patterns that are specific to their websites. Rather than activating editor buttons for every HTML tag, we stripped the list of built-in features down to a bare minimum: links, lists, emphasis tags, heading tags and similarly unambiguous markup elements. Then, we identified common patterns in the website’s HTML and turned them into custom plugins for the WYSIWYG editor.

The Post Snippets plugin for WordPress simplifies complex markup, such as for captioned figures. (Large view18)

One simple example is a button that inserts an attributed quotation, complete with the author’s name and a link to the article it appears in. The initial version inserted the markup with placeholder text for writers to change themselves. Subsequent refinements added a popup editing window with fill-in-the-blank fields for the quote, attribution and link. Capturing that design element in a single-click button made it simpler for content authors, and it ensured that the same semantic structure was used across the website.

The best news is that standard WYSIWYG editors for most CMSes are extremely customizable. With a few lines of PHP, administrators can strip unwanted options from WordPress’ WYSIWYG editor19; define new buttons that insert custom markup structure; and add style options that apply website-specific CSS rules for editors. Drupal’s popular WYSIWYG API20 module offers similar flexibility: Options may be removed, new buttons and drop-downs added, and house styles applied without throwing content authors into the deep end of HTML.

Don’t Sweat the Oddball Pages Link

After all this talk about avoiding raw HTML markup, it’s easy to believe that everything on the website would be carefully planned, modeled and templated. Sadly, almost every website has a number of exceptions that refuse to fit the platonic ideal of structured content. Infrequently updated edge cases — such as terms of service, frequently asked questions and temporary landing pages for marketing campaigns — all tend to break the mold.

One of our client’s websites had several dozen pages like that. We’d used many of the techniques above to streamline their blog posts, news articles, celebrity biographies and photo galleries to good effect. Still, a frustrating mix of exceptions remained on the table. Creating dedicated content types to model the structure of each special case felt like a poor investment: Those pages were seldom reused, and once created, they rarely changed.

Rather than twist the more common content types to fit those uncommon (and often unpredictable) needs, we carved out a compromise: the generic “Blob” content type. It offers a simple title and a classic HTML blob21 field. Editors and marketing team members could insert arbitrary markup, even attaching custom CSS and JavaScript if necessary.

Isolating these uncommon but inevitable blobs protects your long-lived content assets from messy hacks. Ensuring that everything doesn’t eventually become a special case is also important. In the organization above, only a small number of users were given access to the “Blob” content type. A senior editor also kept a close watch to ensure that any common patterns eventually became dedicated, cleanly modeled content types.

Putting The Pieces Together Link

Taken together, the following set of techniques has served us well in a number of large thorny projects:

  • Allow editors to decide about prioritization and emphasis, rather than about explicit visual styling and positioning. This makes cross-channel reuse much easier and allows a website or app’s design system to do its job.
  • Complement structured fields with embedding tags when rich content is part of an article’s narrative flow. This enables editors to reuse content more efficiently across the website and to avoid ugly HTML blobs in body text.
  • Pare down the HTML features of the WYSIWYG editor. Configure the editor and leverage CMS add-ons to give content creators shortcuts to the website’s commonly used markup patterns.
  • Finally, use a dedicated “grab bag” content type when oddball pages need special handling. This will keep the core content types clean and structured, while still accounting for one-off blobs of markup.

Obviously, these approaches won’t solve all of the crazy collisions between structured content and editorial design tweaks. Each website brings unique challenges, and the needs of each content team ensure that we’ll never run out of new requirements. They’re a strong starting point and can quickly be implemented in most modern CMSes. If you have any war stories or useful solutions to similar problems, speak up!

Source of image on front page: opensourceway22

(al) (ea)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22

↑ Back to top Tweet itShare on Facebook

Jeff Eaton is a Digital Strategist at Lullabot, where he designs and implements large-scale web platforms for media, education, and enterprise businesses. He's also the co-author of O'Reilly Media's Using Drupal; the host of the Insert Content Here content strategy podcast; and a frequent writer and speaker at web and open source conferences. In a previous life, he worked as a freelance writer and a copy editor, jobs that he recalls fondly while building editorial tools for today's content teams.

  1. 1

    Robert Jakobson

    June 26, 2013 9:44 am

    Could you go into more detail how emphasis is added to content and transmitted to content partners?

    • 2

      In the case of the Drupal site described in the article, “emphasis” is used in a couple of different ways. We have a large set of design templates for the articles — four or five that are used when articles are featured on the home page; two or three that are used when teasers of the articles are shown on other listing pages; and three that are used when an article is displayed on its own standalone page. There are also some CSS rules governing how the articles with different emphasis styles respond to changing viewports.

      An editor selects the emphasis for an article, and the theme has a handful of switch statements that either change the template used to render the article, or switch up the CSS classes used on the article’s wrapper, depending on the context it’s being viewed in.

      The system isn’t perfect, and this particular site is still under development. (It’s getting close — we’ll see how the system evolves before the final launch.) There are a handful of special cases we think we may need to add later, for temporary, one-off additions to the home page that don’t match an article’s usual presentation style, but it looks like it will work well for the majority of the content in use on the site.

      When content is handed off to partners via a content API, or simple XML and JSON feeds, the ’emphasis’ value is just one of the fields that’s passed along. That allows the receiving system to do whatever template-switching or presentation-tweaking it needs to do, or ignore the emphasis information entirely to treat all articles as “generic” ones.

  2. 3

    Hey, our CMS uses a legacy version of CKeditor, and to get around messy and un-adaptable content generated by users I paste temporary Jquery hacks into the source code at the bottom of the page (like removing attributes from spans, paragraphs and tables). This means if the script is taken out of context and breaks the software (jQuery is powerful stuff) I can quickly remove it. Not bullet-proof, or sound, but it works on the fly.

    • 4

      That sounds like it could be pretty labor-intensive! I haven’t waded into the details recently, but CKEditor has its own native functions to scrub HTML and remove unwanted tags or attributes. You might consider hooking into CKEditor’s plugin architecture to automate that cleaning process when editors paste in terrifyingly bad HTML.

    • 5

      In CKEditor 4.1, a new feature was added to fix precisely this problem: “Advanced Content Filter” — see

      By default, it will only allow the HTML that each used plugin may generate.
      But … you can also configure it to only allow the tags and attributes that you want your content creators to be able to use! Anything else will be stripped. This is exactly what Drupal 8 does out-of-the-box.

      So you may want to consider upgrading from your legacy version :)

  3. 6

    Adam Nemeth

    June 26, 2013 1:45 pm

    I asked a friend, who’s an editor at (the largest online newspaper in Hungary), and also has friends in the team of (the “other” largest online newspaper)

    Both of these sites have millions of unique visitors per month and are clear market leaders in providing daily news on the internet. Both of these sites come from a net-only background. Both sites got their new editorial/admin systems somewhat recently (origo this year, index about 2 years ago)

    Some of his insights:
    – While this priority thingy was implemented at both places, it’s not used for the home page; that is edited through a homepage editor, which has drag-n-drop reordering possibilities, an ability to edit title and lead, and also a built-in image search (which searches for images inside the editorial system)
    – Videos and other media (other than images) are embedded through an “insert object” method, which presents you with a textarea, you paste the embed code, and it shows a preview of it. Since it “eats anything”, I suspect this tool sets width/height of the iframe at most, and otherwise passes raw HTML content (blobs).
    – He thinks it’s done this way as teaching journalists about a markup is unneccessary and complex

    So, this is the state of the art in Hungary, at least. Both sites are responsive, so it seems it works more-or-less.

    • 7

      Adam, thanks for the info!

      The idea of the home page as a special case is one that we’ve seen quite often, too. Depending on the organization, and the emphasis that they put on the home page experience, that can definitely make sense. It’s also a function of how much content has to make its way through the home page, and how many hands there are to keep things fresh.

      The “Save a blob, then tell the system where to put it” approach that I think you’re describing for videos and other media can be really useful. It’s similar to the approach we’re using for random embed codes on the new site that I mentioned. Editors can use arbitrary embed HTML for media partners if they need to, but the markup itself is “firewalled” inside of a dedicated field, and the editors use shortcode-style syntax to place the media within the main body text.

      I think your friend is definitely on target regarding the complexity of teaching everyone in an organization about markup. An understanding of HTML will always be helpful for someone who’s creating content for the web, but there’s a lot of complex markup to keep track of when they entre rich content. Simplifying that process — and giving them shortcodes or markup shorthand — can make life easier for everyone involved.

    • 8

      Server Logic has been doing this more recently and presenting their work at the PDX drupal group. An interesting limitation of the editor as designer model using just the editor is that the editor blob does not often extend the bounds of the page. So, if you need to control styles outside of the edit box, you need to do a bit more.

      Olivia ended up creating a ctools style plugin for this:

      I’d love to get away from spending my time building pages individually.

  4. 9

    Great post, and relevant to a challenge I’ve been having. Recently I wanted to create a community based website that would allow for multiple editors to post news with a consistent look and feel, as well as making use of workflows, and I’ve been trying my hand at Drupal again just because I feel it’s more flexible for this than WP. I feel like I’ve been falling over myself trying to account for every possible technical failure that could come from the editor’s end: broken layouts, badly sized images etc.. Learnt some interesting stuff here, and your company site.

  5. 10


    July 1, 2013 8:14 am

    Just as writers have industry set style guides for how to format their writing, (AP Style), it would be nice if there was some kind of standard for how to format HTML for publishing beyond just the h1, p, strong, em, etc . .

    Mainly the elements which cause more difficulty like image tags, video tags, pull quotes, etc. There are so many rogue hacks for how to pull off the edge cases.

    The problem is that organizations are creating content models that work for their organization but it makes it difficult when working in cross channels.

    It would also make it easier for the designer/developer jumping into the organization to know that they code their content according to the “blank” style guide. Then people would know what to expect when they jump in and make it easier to get up and running and more importantly, form consensus.

    This is similar to style guides for actual code writing such as the Google Style Guides, etc . . . If you know “x” company codes to that style, you automatically create consistency among code bases.

    Maybe this syntax would already be baked into the editor, making it one less thing for developers to configure?

    Is there anything like this that exists already?

    • 11

      CodeAndNotes, this is definitely the direction that the ‘WYSIWYM’ crowd is moving — assistive editing tools that save semantic markup rather than visual/presentation oriented markup. Obviously, the challenge is figuring out what the proper semantics are for a given site! In some cases it will be necessary to capture “house styles” but in others it may be possible to lean on standards like the ones at

      The first and biggest hurdle is killing the idea that the “editing form” should be a perfect reflection of the content’s final appearance. Assistive tools are a huge boon, but it’s easy to give users a length of HTML rope — rope they’ll use to hang themselves given the chance to poke at the markup!

  6. 12


    July 4, 2013 1:44 am

    Hello Jeff,

    Thanks for the post. I am relatively new to the whole content management discussion, and come from the business/marketing background but find the topic and challenges very interesting. I have read a lot about the new content-presentation relationship and its evolution due to to the multiplication of distribution platforms.

    Wouldn’t the solution be to completely separate content and design? I read about a new platform developing that approach – contentful. One would have structured content on one hand and the presentation/design on the other. What do you think of the approach?

    Many thanks in advance!

    • 13

      Complete separation of content from presentation is definitely the holy grail of content reuse. It’s rarely possible on large projects, though, because of the number of edge cases and special exceptions that often come into play.

      Products like Contentful are extremely exciting, but I think a lot of organizations are going to have to layer additional presentation-management tools on top of the “presentation-agnostic” data that’s exposed by its API. That intersection is where a lot of the tough choices are: “This article is the ‘top story’ today. Is that important meta-data about the article, or a one-off decision made in the ‘design’ layer?” The answers will vary from project to project, but it’s definitely where things get complicated.

  7. 14

    Hi Jeff!

    Thanks for this great post. I like that you say that ‘content purist’ and ‘information architects’ have had the domain of structured, semantically rich and multi-media-ready content for themselves for a long time. We also see that is changing and structured content is being adopted much broader.

    In addition to publishing through many devices, an important argument for adding semantics in stead of markup to content is to prepare for content delivery which is personalised and rich of (automated) relations. In our view, ther trends of multi-device and personalization will inenvitably to lead to semantically richt content.

    However, most authors are creatives, and ‘thinking semantics’ is far less natural to many authors then ‘adding markup’. Tools which are specialised in structured and semantically richt content (mostly XML editing tools) have quite a learning curve. This is partly the reason why ‘structured content’ has been quite an ‘elitarian’ activity for a long time.

    At FontoXML, we are trying to bridge that gap and try to bring strcutured authoring to anyone. We do so by translating semantics into logical markup and making the process of adding semantics as intuitive (which means as close to Web- and Word-like paradigms) as possible. In other words: we do completely separate structure from presentation ‘under the hood’ but go lenghts to hide as much of that. Although “WYSIWYG” is not the paradigm of structured content, in order to be ‘assistive’ a tool must stay close to the mark-up thinking that most authors are, and will be, used to.



↑ Back to top