Prioritise Content Over Components

Hi there. Thanks for checking out my talk, Prioritize Content over Components. My name is Simeon Griggs, and I'm from sanity.io, and I primarily want to talk today about content editable websites. And before we get into that, let's have a look at a brief history of editable content when it works on computers.

So here's a very early word processor, perhaps the first on Windows 3.11. Microsoft Word, you might've used this back in the day. We also have Pagemaker. This is one of the first desktop publishing tools on computers. I used Quark Express at my first job. That's how old I am. But desktop publishing has always been concerned with how content looks, not necessarily what it is. And we repeated this when we got onto web publishing as well.

So content editable websites originally using WordPress kind of look like this, and then WordPress evolved to look like this. And now it looks like this. And as it's evolved more and more, it's still been very focused on what the content looks like, not necessarily what the content is. So the CMS, Content Management System Backed Web, it's very concerned with how content looks.

Now, in the second section, I want to talk about when we look at a web page, we might want to ask the question, what's the content model of this page? And this is perhaps a question we're not used to asking ourselves, but it is a really important one too. So if I was building a web page just like this one, and you've probably built web pages just like this one, if I was asked once upon a time, what's the content model of this page? I'd say, what do you mean it's a page? And not really put much more thought into it. Or now we're in a component-driven era for design and web development. I'd probably say, well, it's a header and a hero and a content and a sidebar. But if we have a look at this particular web page again, and really look at what's the actual text on the page? What is its meaning? What is its intent? We can actually break this down. And the data is actually a person's name, is a presenter. We've got a label for text here. We've got a lesson title and a course title. We've got language data. The content model is actually made up of many small individual pieces that happen to be rendered on a web page. And separating the content from its presentation is really the key thought behind this talk here. So when we've got a design focus on what we're doing versus a content focus on what we're doing, our design focus language would be this is a lesson page template. This is a course web page template. This is a presenter web page template.

But if we're looking at the content itself, and that's what we're focused on, we're actually focusing on what those things are, not what they happen to be rendered into at this point in time. It's a lesson, it's a course, and it's a presenter. This is data we're dealing with, not just web pages in presentation or components in presentation. So tell me if this sounds familiar in your career at the moment.

Step one, you need to rebuild a website. What's step two often when it's a content backed website? It's you need to rebuild the CMS because the CMS was locally developed on the previous design only to match that design at that point in time. The content management system wasn't used to house data for what it is. It was used to house data for what it looks like. So let's break that cycle. That's the outcome of this talk today.

So in step three here, explicit curation versus content driven experiences. Again, perhaps some big words that need unpacking. So let's look at it. Here's a mock up for maybe what the next website is going to look like. If we apply an explicit curation lens, we might say this is the hero block because I made it so. I put the hero at the top of the page. I wrote things into it. That's what I want to be there. So that's what it is. And what if we have a web page which actually should be more dynamic? What if we want to customize what we see at any point in time because it's more relevant to the user? If I'm in a part of the world where it's currently summer, which I'm not, perhaps it would be best to put that in the hero. What if I was near a new location that's opening? It would be better if that were the hero. So that thought of having explicit curation, like putting the hero, what it is, because I put it there at this moment in time, it's actually detrimental to your users who might be more benefited by seeing the right content instead of your preferred design at this point in time.

A content-driven application says this is the hero because it's the most relevant. So that's at the top of the page because it's the best content for that user to see at that point in time. And we'll never get this 100% correct. But what I hope you take away from this today is we want to move away just as far as possible, just further to the right here on this diagram, away from explicitly curated experiences and towards content-driven experiences. And you're always going to get asked at the end of the day, but I want to add an auto-playing carousel and a video and add those things. And you're going to have to do those to some small amount, but whatever you can do in your web applications to make them content-driven instead of explicitly curated, like a fine piece of Lego that you've got to click every piece into place, as much as you can make that content-driven and dynamic, the better and longer live that application will be.

So let's put this into practice. Let's build a website.

Here's a website. You've probably built websites like this before. And perhaps your first intention as a designer or a developer is to break this into components. And components aren't bad, but we just need to think about the props that go into those components. So we might break this down as a hero, a banner, a call to action and a label. And these are reasonable. So then we build our code here, and here we have our layout and hero, banner, call to action and label.

And we build those TSX components and we put them in order and style them with classes. And then we need to inject them with some data. So here on the left-hand side, I've got my data and it matches those components. And here is actually where the problem begins, because I've got my hero and banner and call to action, but what's going to happen next? I've taken my data, I've put it into props. Those components render as it is on the right-hand side. And perhaps we take that data structure and put that into a content management system. And so it ends up something like this. And this is great. Your authors are able to modify the text as they need it to be. But what's the next thing that is absolutely going to happen? I guarantee it will happen the day after, maybe the day of launching this website, someone will ask for a change. Actually, the distance doesn't make any sense down there. Can we put it in the subtitle? And actually, can we move the subtitle then down into the image caption, and the date actually needs to be above the folds. We need to move that. And now, so we're sort of moving the props around and our content editable parts are no longer matching what the initial intention of those props were. And now everything works, and we're able to modify and make those changes to the front end as requested, but the data model now makes no sense compared to the front end. Now, you're editing this field called caption, and that happens to be editing the subtitle instead. This is not a good place to be, and the reason why we've got this problem, and so here's the solution, we made it work, but the reason why I've got this problem is because we've modified this, or we've set up this content structure rather, to model what it looked like instead of what all of this content was. So let's go and correct all these mistakes, because this is no way to live.

The problem was not the components. The problem was actually the content. We didn't prioritize the thinking there. If you race to build and design components, and leave the content as an afterthought, this is the sort of trap it's very easy to get yourself into. And it's not the content itself on the right hand side, but rather the structure of the content.

These keys are the problem. We shouldn't be modeling a hero or a banner or a call to action, because we don't actually know what any of those things mean without the values, but if instead we modeled an event, which is what we actually were looking at, and model the title and the subtitle, the distance of that event, then it doesn't actually matter where we put those things on the front end, and the content editing experience of it will always make sense, because I'm not editing a hero subtitle. I'm actually modifying the subtitle of the thing, and it doesn't matter where it's going to be rendered on the front end, because it's always going to be the subtitle of an event.

The major takeaway I'd like you to take from this talk today is that when we've got a hero title or an event title, these are the two data structures that we could have. On the left-hand side, that's our presentation as data. We've modeled what this thing looks like in this component, in this design, at this point in time. The content's unknown. A hero title could be literally any piece of text, and we don't know. The display is rigid. If you're not rendering the hero.title data structure into the hero title, you've got a complete disconnect between your developers and your authors, and the meaning is implied, but it's not explicit.

If instead, on the right-hand side, we're thinking about content for what it is, instead of what it looks like, this is called content as data. The presentation is unbounded. We can render the event title in the h1. We could also render it in a sidebar, where it makes sense, and it doesn't actually matter, because it's always going to be the event title. The display is flexible. The meaning is explicit, and so that content authoring experience is much more relatable for content authors, and the front end can still be rendered as you need it to be.

In summary, consider what something is, not what it looks like. Treat your website as just one outlet for your content. Content-driven designs are so much longer lasting than curated designs. The only way to approach this is to think about it very early. Have conversations before the first pixel is pushed, before the first line of code is written. This talk is mostly based off of a blog post I wrote a short time ago called Prioritize Content Over Components if you'd like to read more about that.