Building a CMS for the responsive web

Building a CMS for the responsive web

In light of responsive web design, people often focus heavily on how content should be rendered, but how it is produced is usually overlooked. This talk will review how the challenges of responsive web design can bleed into issues of content production, and how the Guardian solves these issues with Composer – our web-based, digital content-management system.

D97317c84e6f6bbccb2732b619648c03?s=128

Oliver Joseph Ash

August 28, 2014
Tweet

Transcript

  1. Oliver Ash & Sébastien Cevey The Guardian (@OliverJAsh and @theefer)

    Building a CMS for the responsive web
  2. The Guardian’s new CMS Composer – Rich AngularJS SPA Scribe

    – Open Source rich-text editor
  3. Why build our own CMS? Because it’s fun Because we’re

    special Because we’re smarter than other people Because we had to
  4. Why build our own CMS? 1. Rich content model 2.

    Responsive presentation
  5. Rich content model

  6. Rich content model [[ Picture of newspaper page to highlight

    richness ]]
  7. Rich content model [[ Picture of newspaper page to highlight

    richness ]]
  8. Rich content model [[ Screenshots showing rich page (Bison? Liveblog

    with embeds?) ]]
  9. Rich content model [[ Screenshots showing rich page (Bison? Liveblog

    with embeds?) ]]
  10. Rich content model

  11. Rich content model

  12. Rich content model • Fields & metadata • Document structure

    • Semantic markup • Embeds
  13. • Fields & metadata • Document structure • Semantic markup

    • Embeds Rich content model
  14. Many standard fields Section Headline Standfirst Main image Byline and

    contributors
  15. Many standard fields Link text Trail text Trail image

  16. Many standard fields

  17. Fields & metadata – automation • Automate manual labour ◦

    Sensible defaults ◦ Allow overrides
  18. Rich content model • Fields & metadata • Document structure

    • Semantic markup • Embeds
  19. Before: HTML blob Too loose for our needs: • Standard

    structure for frontends to consume • Support a variety of content types • Ability to record metadata, alternative assets After: JSON structure Document structure
  20. Document structure Block Element Asset Block Element Asset ... ...

    ... Body
  21. Liveblog structure Block Element (text) Asset Block Element (image) Asset

    ... title: “GOAL! Liverpool 2-1 Southampton” keyEvent: true text: “<p>He’s got his goal!</p>” caption: “Daniel Sturridge..” alt: “Daniel Sturridge…” ... Element (text) text: “<p><strong>76 min:</strong> Lambert…” url: “http://static.guim.co.uk/...” width: 460 ... url: “http://static.guim.co.uk/...” width: 1024 ...
  22. Liveblog structure

  23. Article structure Block Element (text) Element (video) text: “<p>Many of

    his tweets...” html: “<iframe src=”...” ... Element (text) Element (tweet) text: “<p>(“How to wash...” html: “<blockquote class=”tweet”..” ...
  24. Gallery structure Block Element (image) Asset caption: “New York City,

    ...” alt: “New York City, 2000” ... url: “http://static.guim.co.uk/...” width: 1024 ... ... Element (image) Asset caption: “Portugal, 1976 ...” alt: “Portugal, 1976” ... url: “http://static.guim.co.uk/...” width: 1024 ... ...
  25. Document structure – summary • JSON tree structure • Metadata

    records at all levels • Helps drive features based on semantics (updates, multiple assets for an image, etc.)
  26. Rich content model • Fields & metadata • Document structure

    • Semantic markup • Embeds
  27. Semantic markup • HTML used for marking up text (body,

    caption) ◦ Inline formatting ◦ Lists ◦ Blockquotes • HTML used for semantics, not presentation ◦ <p>, <ul>, etc. ◦ <b> ⇒ <strong>, etc Enforced by our rich-text editor, Scribe https://github.com/guardian/scribe
  28. Semantic markup – user misbehaviour Actual content: <p>• Some text<br>

    • Some "text"</p> Desired semantic content: <ul> <li>Some text</li> <li>Some “text”</li> </ul>
  29. Semantic markup – why? • Easier to style (e.g. bullet

    point character) • Readable by robots - Googlebot, Pocket, our own... • SEO
  30. Semantic markup Don’t let editors write HTML. Ever. ⇒ Use

    our Scribe rich-text editor Do The Right Thing by default. ⇒ Enforce correct behaviour using plugins
  31. Rich content model • Fields & metadata • Document structure

    • Semantic markup • Embeds
  32. Embeds • Various third party content ◦ videos (YouTube, Vimeo,

    etc) ◦ maps (Google) ◦ tweets ◦ audio (SoundCloud, Spotify) ◦ documents (Google Docs) • Our own content ◦ Guardian Video ◦ Guardian Witness ◦ Guardian Discussion (comments)
  33. Embeds – embed codes

  34. Embeds – embed codes • Tedious manual process • Error

    prone ◦ Invalid syntax ◦ Insecure or malicious HTML/JavaScript • HTML blob, no metadata
  35. • Relies on embed.ly + other custom resolvers • Fast

    ◦ Embeds are more frequent, driving engagement • Resilient • Collect metadata programmatically ◦ Enables analytics ◦ Potentially used for fallback content Embeds – automatic URL resolution
  36. Embeds – analytics

  37. None
  38. None
  39. Embeds – sample YouTube metadata elementType: "video" source: "YouTube" url:

    "https://www.youtube.com/watch?v=XS6ysDFTbLU" description: "Bill Gates accepts Mark Zuckerberg's ALS…" title: "Bill Gates ALS Ice Bucket Challenge" html: "<iframe width=\"460\" height=\"259\" src=\"https://…" authorName: "thegatesnotes" ... Element (video)
  40. Embeds – custom code <script src="//idiotic.io/dogue.js"></script> <script> Dogue.install(); </script>

  41. Embeds – custom code <script src="//idiotic.io/dogue.js" async></script> <script> Dogue.install(); //

    ReferenceError: // Dogue is not defined! </script>
  42. Embeds – custom code sandbox Sandbox content into <iframe> using

    Fence: • Uses srcdoc (via polyfill) • Adapts dimensions • Doesn’t block rendering https://github.com/guardian/fence
  43. Embeds – Fence example <iframe class="fenced" srcdoc="<script src='//idiotic.io/dogue. js'></script><script>Dogue.install(); </script>"></iframe>

    // Use fence.js var q = 'iframe.fenced'; var node = document.querySelector(q); fence.render(node);
  44. Embeds – scripted components When we want: • Break out

    of <iframe> • Better fallback • More control, more power! a.k.a. “interactives” from our interactive team or contracted third-parties
  45. None
  46. Embeds – scripted components Historically, scripts injected into the page,

    take over • Not resilient • Not cross-platform • No fallback • Content not accessible by editors
  47. Embeds – enhancer Target an element with a “boot” script

    (AMD module) that progressively enhances its contents. <figure class="interactive" data-interactive="http://gu.com/iframe-wrapper.js "> <a href="http://gu.com/sample/content.html ">Grazing bisons</a> </figure> https://github.com/guardian/enhancer
  48. • Embedded content: increases engagement • Automatically resolve URLs to

    elements ◦ Faster, less error-prone ◦ Increased metadata • Custom embed code ◦ Sandbox via Fence • Scripted components ◦ Progressive enhancement via Enhancer Embeds – summary
  49. Rich content model – summary • Automation and intuitive UI

    to reduce editorial cost • JSON structure to record metadata and assets • 3 tiers of embeds for different scenarios
  50. Responsive presentation

  51. Responsive presentation • Multiple frontends • Rich responsive layout •

    Responsive embeds • Speed & performance
  52. Responsive presentation • Multiple frontends • Rich responsive layout •

    Responsive embeds • Speed & performance
  53. Responsive web design • One website, many devices Multiple frontends

    http://www.theguardian.com/
  54. None
  55. Multiple frontends Responsive content • Multiple frontends • Another dimension

    of RWD Content Content API ?
  56. Multiple frontends – WYSI NOT WYG The CMS cannot render

    final result: • Too many frontends • Frontends change very quickly • Devices may differ (no JS, touchscreen, etc.) Editors are responsible for content Frontends are responsible for presentation
  57. None
  58. None
  59. Responsive presentation • Multiple frontends • Rich responsive layout •

    Responsive embeds • Speed & performance
  60. Element weighting • Editorial hints for the presentation layer •

    Depends on frontend and breakpoint
  61. None
  62. None
  63. None
  64. Pull quotes elementType: "pullquote" html: "<p>That’s the thing that is

    partly..." attribution: "Tracy Droz Tragos" Element (pullquote)
  65. Responsive presentation • Multiple frontends • Rich responsive layout •

    Responsive embeds • Speed & performance
  66. Responsive embeds Embedded by URL CSS trick using fixed-ratio wrapper

    <iframe> sandbox Auto-sizing by Fence Scripted components In the document or <iframe> with standard resizing hooks using postMessage
  67. Responsive presentation • Multiple frontends • Rich responsive layout •

    Responsive embeds • Speed & performance
  68. Speed & performance Exploit JSON structure to: • Default to

    smaller image assets • Pick the best video encodings • Render tweets only on tablet/desktop • etc.
  69. Responsive presentation – summary • Not WYSIWYG • Editors influence

    presentation through metadata • JSON structure enables frontends to make better choices
  70. Conclusion • Richer data model but faster to work with

    • Guarantee correctness and resilience • Edit content (semantics), derive presentation A good content model should enable richer and more responsive presentation
  71. Thank you! Any questions? Psst, we are hiring! http://developers.theguardian.com/