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.

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
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
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/
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
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
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/