Platonic Content

The modern Web is changing, rapidly. That should not be news to anyone who has been paying attention lately, of course. New technologies, techniques, and use cases are forcing developers to rethink how they design systems, sites, look & feel, and platforms. Pick a buzzword and it has probably caused some radical shift in thinking in recent years.

But are they really all that different? Have the changes in recent years all been pulling us in different directions, or are they pulling us in the same direction? In fact, viewed through the right lens there is only one change. It's a change that is fundamental to the Web, and really to all digital information. We just view it through three different lenses, depending on the task at hand. In fact, lenses are exactly how we should understand it.

Design Systems

The Rise of Mobile™ has forced many designers to rethink how they approach a Web page. Those who held onto the fixed-width canvas for years have been forced to finally accept that the Web canvas is different, flexible, variable, and a completely different challenge than they were once used to. It's simply not possible to design Web "pages" anymore. The word "page" is itself an anachronism. Websites are not a series of pictures but a collection of presented content.

The way to handle that mental shift is to not design pages, but reusable systems and patterns. A design system is a series of rules and patterns for how content will be presented, without knowing the exact piece of content that will be displayed. The shape of the content is known, of course: An event has a description, date, location, price, and representative image. From that knowledge comes a series of patterns, such as:

• How does this event look as the primary thing on a page?
• How does this event look in a list of upcoming events (where an image would be relevant)?
• How does this event look in a list of upcoming events (where an image would not be relevant)?
• How does this event look when "featured" or "promoted" on the home page?
• How does this event look when it is "embedded" into another piece of content (say, a speaker page), or as part of a collection of events, past or present?

And of course, there's also news items, or speakers, or employees, or other pieces of content that may or may not also appear in the same form. How similar (or not) are those?

How does that content relate to each other? Should an event, shown as a primary object, include an embedded version of a speaker? Are there multiple speakers? Should those speakers be links to another page that shows the speaker as primary content?

A design system seeks to answer those questions in a consistent and "big picture" fashion. However, to do so requires understanding content independently of its visual representation at any given time. The content exists unto itself, and different presentations are applied to it in different places at different times in different contexts to provide a cohesive yet flexible presentation.

Content Strategy

Content Strategy is another field that has gotten a lot of attention lately. Content Strategy is the planning, development, and management of content; essentially design of the content structure itself. A major driver of the renewed interest in content strategy is multi-channel content reuse.

"Content" is not just something that shows up in a Web browser on a desktop. It shows up on a Web page on a 3" phone screen, too. Or as syndicated content on some other website. Or in a mobile app. Or as part of a printed handout at an event. Or on a TV via a game console. Or reformatted by Instapaper or other offline reading service. Or read-aloud via a text-to-speech system. Or a Twitter summary card. Or a Google search result teaser. Or played on the radio. Or displayed on your refrigerator.

All of those different use cases require doing very different things to and with the content in question. The content's structure and meaning is the same, but its presentation varies widely. That means, to the extent possible, separating the structure of the content from any given presentation (and HTML is then only one possible presentation). Presentation is something that gets layered on depending on the context, device, and use case.

That gets tricky, of course, when content needs to be "embedded" in other content. Consider a manually-curated list of events that a given speaker has been involved in, which needs to be placed at an arbitrary place in a news item about that speaker. Oy! The fancy name for that process is called "transclusion", and it's one of the harder parts of content strategy and content modeling. The key here again is to embed not a presentation of another piece of content, but a relationship between two pieces of content with potentially rules about how it should be presented... later. The content exists unto itself, and different displays are applied to it in different media at different times for different contexts.

REST

There has also been a renewed interest in web services in recent years, and in REST-style web services in particular. REST stands for REpresentational State Transfer, and is a fairly rigid set of rules for how to communicate between a client and a server; in particular, the client, not the server, is in control of the communication and is responsible for keeping track of the state of a user's interaction; the server is, essentially, "dumb".

There's far more to REST that I won't go into here, including a great deal of misunderstanding. (In short, "just because it uses HTTP doesn't make it RESTful".) The key points we're most interested in, however, are these:

• A resource exists uniquely at a specific URI, and a URI uniquely identifies a resource.
• A piece of content may be a resource, but not all resources are content.
• A resource has relationships (links) to other resources that have semantic meaning.
• A resource may be transferred (client to server or server to client) in any of an infinite number of representations of that resource.

That last point is the most important for our purposes. A given resource may be represented in-transit using JSON, but it could also be represented as XML and still "be" the same resource. It could be represented as an HTML page. It could be a PDF file. Those are all different representations of the same underlying resource. They are — by definition — the same "thing", just represented differently. Many common representation formats — such as the Hypertext Application Language (HAL) used by Drupal 8, Zend Apigility, and many others — allow for related resources to be embedded, in part or in full, in another resource. For the most part that is for efficiency, but can also be used to, for example, easily create a collection of resources by embedding them all in one "collection" resource.

The combined ability to represent the same resource in multiple ways, link to other resources, and embed resources within other resources creates an extremely powerful and flexible basis for a Web service API. One client application can request data in JSON (because that's easier to parse in a browser), another in XML (because it's Java), and another as an SVG graphic to embed into some other system. The underlying resource exists unto itself, but is represented in different ways at different times for different client requests.

Sound familiar?

Notice a pattern emerging? Design systems, content strategy, and RESTful API design are all different facets of the same gem. They are all based on the realization that content must exist independent of how it is presented, and that content relates to content, and content may be included in other content.

"But wait!" I hear you cry, "all that exposition just to get back to 'separate content from presentation?'" Well, yes, but it goes deeper than that. The last round of "separate content from presentation" was all about separating HTML markup from presentation and using CSS for styling. That was a major and important step forward, no question. But the modern Web goes much further than that. In order to serve all the needs of modern content management, we need to understand content not as "semantic markup" but in its pure platonic form.

Content, that which we deliver to customers, clients, and users, exists unto itself, in the abstract. It may be represented (a la REST) in a given medium, in a given way, in a given context, embedded in some other content, but it exists independently of all of them. A content model must exist independently of any of them in order to be reusable in all of them. We need to be able to understand our model on an ideal, platonic level, not just as shadows on a wall — or on a whiteboard, specifically — before we can determine how best to represent it in all the myriad ways it will be called upon.

Bringing Light into the Cave

That's not the whole story, however. Beyond the realization of a next generation of "separate content from presentation" there's something deeper that we can learn. Specifically, that the model beneath design systems, REST, and multi-channel publishing is the same.

All content can be a resource, but not all resources are content. When content is presented as a resource, it is presented at one unique URI/URL. It has meaningful links to related resources/content. What links are meaningful? The same ones that would be meaningful in a REST API. What is the content itself? The same content objects that would be relevant in a non-web context.

Web pages are simply a REST API where the representation is HTML, and multi-channel publishing requires the same strong platonic content modeling as a REST API.

When designing a page as part of a design system, include only those elements that relate to a piece of content, that are relevant in context, that you would want the REST API version of that same page to have. That REST API may well be powering your refrigerator, radio station, and the app that assembles your Flipboard magazines, too. Or if not, you're still dealing with the same underlying content.

The key understanding is that content, information, exists independently of its medium. It has a pure, platonic form. The shadow we see cast on a Web page, Web service, or kitchen appliance is simply the result of the lens we apply to it. To understand our content, and to be able to apply whatever lens or filter to it we want, we must stop looking at and designing shadows. Our job, as architects and designers, is to look away from the shadow and understand the content as it really is, in the abstract, and then focus the light to present the appropriate shadow to the appropriate people at the appropriate time.

And step one of that job is the same, regardless of what type of shadow (device) you're serving: Understand your content.