Creating Content for the Web
For as long as I can remember, creating content on a computer has always been the same. First it was creating documents with word processors like Microsoft Word. From there I graduated to writing emails, and eventually into using (and building) websites that utilized Content Management Systems (CMSs).
Most of us are familiar with this interface:
When you're creating a document in your word processor, you select the size of the paper and start creating. What You See Is What You Get (WYSIWYG) editors in most CMSs have historically adopted this same approach to adding content to a website. This was fine when the vast majority of webpages were viewed on a computer monitor; there was still a standard size (or couple of sizes) that would work most of the time. We could create pages with statically placed images and hard defined widths. There was much rejoicing.
But the web has started to change. We no longer all visit the internet on the same small subset of devices. Someone might be reading this blog post on their laptop, while others might be reading it on their smartphones. And some of us nerds even visit websites on their 4k TV just to prove a point.
This is where the WYSIWYG model breaks down. Statically placed content won't move or resize when viewed on something other than the device for which it was designed. Content management systems have typically solved this problem by creating fielded content entry forms that fill content-specific templates. These templates can then be manipulated to display in different ways on different devices.
Drupal is a good example of this approach. Content entry in Drupal has always followed a certain style that I like to refer to as "Mad Libs" content entry. We have a front-end template, and we use a form on the back end to fill in the missing content. It looks a little bit like this:
This works great for structured content like an employee bio, but breaks down when trying to create more malleable content like blog posts or articles. Take this blog post, for instance. I've got a mix of text and images, but that mix is going to be different for every blog I write.
Content Entry Needs to Be Responsive
I know, I know... change is bad. But we're going to need to change the way we think about content entry on the web. The new approach is to think of a web page as a collection of “layers” or “slices”. Each slice is its own self-contained entity, and these are stacked together to create the full web page that gets displayed to the end user.
An example might be helpful here. Let’s say we’re building a blog post. Now, most blog posts are a collection of text and images, right? Some may be more text-heavy (or image-heavy), but at the the end of the day we’re looking for a good mix. With this content slice method, the user is given a different looking authoring interface. Instead of the WYSIWYG box, they have the ability to add layers of content to their page. To keep it simple, let’s imagine a couple of basic entities:
- An Image layer: this displays a full-width image
- A Text layer: a place to enter paragraphs of text
- A Text/Image layer: a combination of the two, where you can add an image and text, and select on which side of the text the image sits.
The author can add these as they see fit. Perhaps we start with a header image (image layer), and then an introductory paragraph (text layer). The next paragraph could have a smaller image to illustrate a point in the text (text/image layer). And so on.
As we can see, the content author can add content with the flexibility that they’d be used to when creating a Word document while still conforming to the constraints of writing content in a responsive medium. By this I mean, each layer can be coded to fit within the design of the website itself. So no more worrying about how content looks across the site -- it’ll all fit in the theme while still being one-of-a-kind.
And this is just the beginning. We can expand this concept to take full advantage of the power of a modern CMS: instead of having a simple image layer, why not a “related content” layer that the author can use to choose which of their other articles should show up? Or a “code” layer for those bloggers who like to intersperse code examples in their blogs?
In this way we can give our content creators the freedom they need to create engaging content, while still having enough control over the final outcome to make sure it all works flawlessly for the end users of the site.
If you want to see how this is being done today, read more about how I've used Responsive Paragraphs with Materialize for Drupal 8 to create this website (and this blog!).