Successfully reported this slideshow.
Your SlideShare is downloading. ×

The Future of-the CMS (Twin Cities DrupalCamp 2015)

Ad

Twin Cities DrupalCamp | June 27, 2015
The Future of the CMS
Headless architecture, multiple frontends, and

content as a ...

Ad

Todd Ross Nienkerk
Digital Strategist and Partner

Four Kitchens
@toddross
todd@fourkitchens.com

Ad

I want you to rethink the
role of designers, the
purpose of a CMS, and
how we manage and
consume content.

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Loading in …3
×

Check these out next

1 of 75 Ad
1 of 75 Ad

The Future of-the CMS (Twin Cities DrupalCamp 2015)

Download to read offline

In this session, we will rethink the role of designers, the purpose of a CMS, and how we manage and consume content. We will discuss:

(1) The tension between a design and a CMS. Should your design be optimized for your CMS? Or should you modify your CMS to achieve your design? In other words, are you walking the dog, or is the dog walking you?

(2) "Headless" Drupal: Drupal as a backend with multiple frontends. Drupal's theming layer is difficult to master and expensive to upgrade between major releases. We will discuss how the frontend and backend can be decoupled to provide better experiences for users, developers, and designers alike.

(3) Content as a service. Decoupling isn't just about separating the frontend from the backend or making upgrades easier. In fact, the real power of headless Drupal is separating content from presentation, allowing you to connect any number of websites, channels, or devices to a single source of content through an API!

(4) TWiT.tv case study. We'll close by discussing how Four Kitchens work with This Week in Tech to relaunch TWiT.tv as a decoupled Drupal site with an exposed API allowing their fanbase to directly access content.

Get ready for some really big, innovative ideas!

(This session was delivered at Twin Cities DrupalCamp on June 27, 2015.)

In this session, we will rethink the role of designers, the purpose of a CMS, and how we manage and consume content. We will discuss:

(1) The tension between a design and a CMS. Should your design be optimized for your CMS? Or should you modify your CMS to achieve your design? In other words, are you walking the dog, or is the dog walking you?

(2) "Headless" Drupal: Drupal as a backend with multiple frontends. Drupal's theming layer is difficult to master and expensive to upgrade between major releases. We will discuss how the frontend and backend can be decoupled to provide better experiences for users, developers, and designers alike.

(3) Content as a service. Decoupling isn't just about separating the frontend from the backend or making upgrades easier. In fact, the real power of headless Drupal is separating content from presentation, allowing you to connect any number of websites, channels, or devices to a single source of content through an API!

(4) TWiT.tv case study. We'll close by discussing how Four Kitchens work with This Week in Tech to relaunch TWiT.tv as a decoupled Drupal site with an exposed API allowing their fanbase to directly access content.

Get ready for some really big, innovative ideas!

(This session was delivered at Twin Cities DrupalCamp on June 27, 2015.)

Advertisement
Advertisement

More Related Content

Advertisement

The Future of-the CMS (Twin Cities DrupalCamp 2015)

  1. 1. Twin Cities DrupalCamp | June 27, 2015 The Future of the CMS Headless architecture, multiple frontends, and
 content as a service
  2. 2. Todd Ross Nienkerk Digital Strategist and Partner
 Four Kitchens @toddross todd@fourkitchens.com
  3. 3. I want you to rethink the role of designers, the purpose of a CMS, and how we manage and consume content.
  4. 4. What designers actually do Agenda 1 32 4 5
  5. 5. The tension between a design and a CMS Agenda 3 421 5
  6. 6. What “headless” means 1Agenda 432 5
  7. 7. When headless makes sense 1Agenda 2 3 4 5
  8. 8. What’s next 321Agenda 4 5
  9. 9. What designers actually do 1 32 4 5
  10. 10. Photo: eddiecoyote via Flickr (Creative Commons BY) In the old days...
  11. 11. Photo: Snak Shak via Flickr (Creative Commons BY-NC) Today’s websites…
  12. 12. Photo: Snak Shak via Flickr (Creative Commons BY-NC) Today’s websites…
 are actually web systems
  13. 13. Illustration: Adam Snetman Designers and developers …and frontend developers
  14. 14. Designers determine a site’s functionality
  15. 15. Credits EASY
  16. 16. Credits HARD
  17. 17. Credits HARD
  18. 18. Designers are a site’s primary architects
  19. 19. The tension between a design and a CMS 3 41 2 5
  20. 20. Who’s walking whom? CMS Design
  21. 21. Two philosophies of designing for a CMS
  22. 22. CMS first • The user’s needs are important, but there are many ways to satisfy them • The design can be changed to align with the natural behavior of the CMS • The end result is easier and cheaper to maintain
  23. 23. Design first • The user’s needs are paramount and non-negotiable • The design must be executed as-is • This may involve hacking the CMS or creating a complicated codebase, which affects maintainability
  24. 24. Neither philosophy is wrong
  25. 25. Maybe we can satisfy both
  26. 26. What “headless” means 1 432 5
  27. 27. CMS Frontend Backend
  28. 28. Frontend CMS Backend
  29. 29. Frontend CMS Backend Head Headless Body
  30. 30. Frontend CMS Backend
  31. 31. Web Backend
  32. 32. Web Backend Mobile Native
 apps Feeds Screen
 readers Social
 mediaXbox Wear-
 ables
  33. 33. Web Backend Mobile Native
 apps Feeds Screen
 readers Social
 mediaXbox Wear-
 ables
  34. 34. Web Content Mobile Native
 apps Feeds Screen
 readers Social
 mediaXbox Wear-
 ables
  35. 35. When headless makes sense 1 2 3 4 5
  36. 36. Adopt cutting-edge frontend technologies Headless makes sense when you want to…
  37. 37. Backend safe repeatable known solutions,
 expected results Frontend safe repeatable known solutions,
 expected results BORING
  38. 38. Frontend bleeding-edge tech richest experience high risk, high reward Backend bleeding-edge tech richest experience high risk, high reward DANGEROUS
  39. 39. JUST RIGHT Frontend bleeding-edge tech richest experience high risk, high reward Backend safe repeatable known solutions,
 expected results
  40. 40. Separate upgrades from redesigns Headless makes sense when you want to…
  41. 41. Redesign New CMS Upgrade CMS Redesign Redesign Upgrade CMS Redesign Upgrade CMS Coupled CMS Time
  42. 42. Redesign New CMS Redesign Upgrade CMS Redesign Time Decoupled CMS
  43. 43. Redesign New CMS Redesign Redesign RedesignRedesign Redesign Upgrade CMS Time Decoupled CMS
  44. 44. Centralize your content Headless makes sense when you want to…
  45. 45. My
 website CMS Content Frank’s
 website CMS Content Sara’s
 website CMS Content Laura’s
 website CMS Content Bob’s
 website CMS Content
  46. 46. My
 website CMS Content
  47. 47. CMS My
 website Content
  48. 48. Me Frank LauraBob Sara Content
 hub
  49. 49. Sara Me
  50. 50. Sara Me
  51. 51. Me Sara
  52. 52. Me Sara
  53. 53. Publish to many frontends and experiences Headless makes sense when you want to…
  54. 54. Web Content
 hub Mobile Native
 apps Feeds Screen
 readers Social
 mediaXbox Wear-
 ables
  55. 55. Web Mobile Native
 apps Feeds Screen
 readers Social
 mediaXbox Wear-
 ables
  56. 56. Web Mobile Native
 apps Feeds Screen
 readers Social
 mediaXbox Wear-
 ables
  57. 57. Make your content easily accessible to via an API Headless makes sense when you want to…
  58. 58. Web Content
 hub Mobile Native
 apps Feeds Social
 mediaXbox Wear-
 ables
  59. 59. Web Content
 hub Mobile Native
 apps Feeds Social
 mediaXbox Wear-
 ables Public API Fan site News
 reader
  60. 60. Why TWiT went headless
  61. 61. Source: Leo Laporte’s announcement (4ktch.in/twittv-leo) “[It’s] faster and easier to create new sites. Web design styles change faster than high fashion, so it's nice to be able to update the site without re-doing all the hard work on the backend.”
  62. 62. Source: Leo Laporte’s announcement (4ktch.in/twittv-leo) “Having a complete API would make it easier to do apps. The app, just like the website, would have access to everything there is to know about TWiT, in a simple, accessible fashion.”
  63. 63. Source: Leo Laporte’s announcement (4ktch.in/twittv-leo) “By making the API public, we encourage members of our audience to create new things, things we might never have thought of. You could even design a website you like better. Abstracting the content from the presentation seems like a big win.”
  64. 64. Source: Leo Laporte’s announcement (4ktch.in/twittv-leo) “By keeping Drupal simple and avoiding additional third- party modules, we can make a more secure and reliable backend that will be much easier to upgrade when future versions of Drupal arrive.”
  65. 65. • TWiT’s case study: 4ktch.in/twittv-leo • 4K’s blog post: 4ktch.in/twittv-4k • API documentation: docs.twittv.apiary.io • You can consume content the same way TWiT’s website does! • Saucier: github.com/fourkitchens/saucier • Our open-source Node.js framework for building headless Drupal sites
  66. 66. What’s next 1 2 3 4 5
  67. 67. Content comes first
  68. 68. We must design for experiences, not just devices
  69. 69. Frontend technologies are accelerating, and CMSs can’t keep pace
  70. 70. Rise of WMSs (Website Management Systems) and services like Squarespace
  71. 71. Return of (small) static websites
  72. 72. Questions?
  73. 73. Thank you! All content in this presentation, except where noted otherwise, is Creative Commons Attribution-ShareAlike 3.0 licensed and copyright Four Kitchens, LLC.
  74. 74. Credits • The following icons are from the Noun Project and are licensed Creative Commons BY 3.0: Dog-walking illustration based on an icon by Pavel Nikandrov; Laptop icon by B. Agustín Amenábar Larraín; Tablet icon by Pham Thi Dieu Linh; Smartphone icon by George Agpoon; Media icon by Garrett Knoll; Text icon by Julien Miclo; Chat icon by Dolly Vu; Document icon by Nimal Raj. • Drupal is a registered trademark of Dries Buytaert. • The assets listed above, as well as any assets specifically noted on a slide, are exempt from this presentation’s Creative Commons BY-SA 3.0 license. • Special thanks to Adam Snetman and Aaron Stanush. They helped create and deliver earlier versions of this presentation, and much of their sense of humor and style have been retained in this current iteration.

×