Eaton & Urbina: structured, intelligent and adaptive content
While walking, I started listening to Jeff Eaton’s Insert Content Here
podcast, episode 25: Noz Urbina Explains Adaptive Content
. People must’ve looked strangely at me because I was smiling and nodding — still walking :) Thanks Jeff & Noz!
Jeff Eaton explained how the web world looks at and defines the term WYSIWYG. Turns out that in the semi-structured, non-web world that Noz comes from, WYSIWYG has a totally different interpretation. And they ended renaming it to what it really was: WYSIWOO.
Jeff also asked Noz what “adaptive content” is exactly. Adaptive content is a more specialized/advanced form of structured content, and in fact “structured content”, “intelligent content” and “adaptive content” form a hierarchy:
- structured content
- intelligent content
- adaptive content
- intelligent content
In other words, adaptive content is also intelligent and structured; intelligent content is also structured, but not all structured content is also intelligent or adaptive, nor is all intelligent content also adaptive.
Basically, intelligent content better captures the precise semantics (e.g. not a section, but a product description). Adaptive content is about using those semantics, plus additional metadata (“hints”) that content editors specify, to adapt the content to the context it is being viewed in. E.g. different messaging for authenticated versus anonymous users, or different nuances depending on how the visitor ended up on the current page (in other words: personalization).
Noz gave an excellent example of how adaptive content can be put to good use: he described how we he had arrived in Utrecht in the Netherlands after a long flight, “checked in” to Utrecht on Facebook, and then Facebook suggested to him 3 open restaurants, including cuisine type and walking distance relative to his current position. He felt like thanking Facebook for these ads — which obviously is a rare thing, to be grateful for ads!
Finally, a wonderful quote from Noz Urbina that captures the essence of content modeling:
How descriptive do we make it without making it restrictive?
If it isn’t clear by now — go listen to that podcast! It’s well worth the 38 minutes of listening. I only captured a few of the interesting points, to get more people interested and excited.1
What about adaptive & intelligent content in Drupal 8?
First, see my closely related article Drupal 8: best authoring experience for structured content?
.
Second, while listening, I thought of many ways that Drupal 8 is well-prepared for intelligent & adaptive content. (Drupal already does structured content by means of Field API and the HTML tag restrictions in the body field.) Implementing intelligent & adaptive will surely require experimentation, and different sites/use cases will prefer different solutions, but:
- An
intelligent_contentmodule for Drupal 8: allow site builders/content strategists to define custom HTML tags (e.g.<product_description>) to capture site-specific semantics. A CKEditor Widget could hugely simplify the authoring experience for creating intelligent content, by showing a specific HTML representation while editing (WYSIWOO!), thanks to HTML (Twig) templates associated with those custom HTML tags. - An
adaptive_contentmodule for Drupal 8: a text filter that allows any tag to be wrapped in a<adaptive_content>tag, which specifies the context in which the wrapped content should be shown/hidden. - The latter leads to cacheability problems, because the same content may be rendered in a multitude of different ways, but thanks to cache contexts in Drupal 8 and the fact that text filters can specify cache contexts means adaptive content that is still cacheable is perfectly possible. (This is in fact exactly what it was intended for!) cache contexts
I think that those two modules would be very interesting, useful additions to the Drupal ecosystem. If you are working on this, please let me know — I would love to help!
-
That’s right, this is basically voluntary marketing for Jeff Eaton — you’re welcome, Jeff! ↩︎
Comments
I think the way of https://www.drupal.org/project/atoms more suitable for that vision. So another candidate to port
That seems very similar to https://www.drupal.org/project/paragraphs.
Yes, it is. But it’s already much more flexible (despite the fact it is in early development):
How would you compare this to https://www.drupal.org/project/wysiwyg_fields (see http://realityloop.com/blog/2015/06/17/wysiwyg-fields)?
IMHO that approach holds most promise. But in Drupal 8, that would use https://www.drupal.org/project/entity_embed + CKEditor Widgets, not tokens.
Curious to hear your thoughts!
I strongly STRONGLY against from anything related to WYSIWYG except the things it was designed for (I mean text formatting). It was a long way experimenting (with WYSIWYGs, custom Markdown, custom input filters, custom tokens, pseudo-comments etc etc) but finally I know the truth.
Why not WYSIWYG?
So what?
WYSIWYG should format the text, not page layout. Page layout should be structurized, semantic and stored in the format which is friendly for the CMS.
Like Atoms/Paragraphs do.
Agreed that the WYSIWYG editor should format the text not the page layout.
It’s very difficult to understand what Atoms does exactly, without an explanation/rationale on the project page, and if the demo doesn’t seem to work yet. Of course, it’s only an alpha, so that’s fine, I’m only saying it because it’s then quite difficult to have a meaningful discussion.
To answer your points, as well as possible given that I cannot actually test Atoms:
Thank you for diving in the topic.
I absolutely agree that WYSIWYG could be and should be used for rich text formatting, including basic positioning (like floating images).
I just mean that many and many developers start using WYSIWYG for building layouts. That’s wrong.
Finally please spend 10 min more to learn how Atoms work. That’s really amazing. See my comments your on GitHub issue.
Oh, absolutely! :) I guess you first thought I was advocating for that — definitely not the case!
I’d love to, but I really find the documentation lacking. It’d be great if you could explain what Atoms are, and how one would use “Columns” and “Groups”. In the screenshot I also see “Row”. So it feels very layout-y to me. http://drupal.tonystar.me/atoms also doesn’t really clarify the rationale. I think that’d help your project get more users :)
When talking about structured content, I find that it’s useful to divide things into a couple of basic scenarios.
First, you have your fully templated stuff—content where fields can be made very explicit, can be mapped to a number of different layout or presentation modes, and there isn’t much variation in presentation style from one piece of content to the next. In the Drupal world, we don’t talk about these a lot because we basically get them for free with FieldAPI and type-based templates.
The next step up is content where we can break things down into well-delineated chunks of component content, but those individual chunks are arranged in arbitrary ways from one piece of content to the next. Most “brochureware” designs follow this model: pages tend to be assemblies of short declarative text blurbs, calls to action, and product/service imagery. Tools like Paragraphs, Atoms, and Inline Entity Forms + Entity References can knock these things out of the park in Drupal.
The third category, though, is a bit tricker: large runs of coherent, narrative text that require complex islands of structural content to be positioned inside of the narrative at specific points. Chopping up the long run of narrative text into separate Atoms or Paragraphs or Entities is a bad solution, not unlike the old process of “slicing” JPEGs to fit them into pre-CSS layouts. That’s where assistive tools that allow writers and editors to place complex data inside the body field become important.
As you said, page layout shouldn’t be in the body field, information about placement and position inside of a narrative is just as semantic as information about emphasis or list items. The important part is that we ensure we are capturing the semantic meaning, not just extrapolating it from styling/formatting decisions.
That’s the scenario where WYSIWYG Fields excels: it captures structural information, stores it in a properly denormalized form that’s amenable to querying and filtering, but positions the information inside of a body field using placeholder tokens. I’ve written a lot about this approach and the various forms it takes, and I think it’s critical that we recognize its value.
1) Narrative content != non-structured content. Really. You are talking about narrative content like it does not have structure. Like it just an ordered sequense of text blocks. That’s not true. Books have chapters, chapters have paragraphs. Wiki pages have sub-sections and multi-level headings. Etc etc.
2) Let’s think outside of
<textarea>. Today we are not limited to<textarea>and WYSIWYG to make it usable. We can create another experience for content management. When we creating content in our minds we do not treat it as a text, we are always operating with breakdown structures. So why not to use the same structures for content management systems?3) In examples. Let me to show you how narrative content can benefit from this concept.
A. Classic WYSIWYG example: http://drupal.tonystar.me/sites/default/files/drupal-wysiwyg-narrative.png.
Pros:
Cons:
<h3>which means this section is subsection of<h2>”.B. As opposite, atomic content example: http://drupal.tonystar.me/sites/default/files/drupal-atoms-narrative.png.
Pros:
Cons:
To me, Atoms very much feels like an alternative to having to create proper content types, it feels like avoiding Entity API and Field API. (Yes, I know it uses those internally too.)
Which brings me to one of the key questions I’ve had all along: how can Atoms-based content types be listed/reused in Views?
;-)
Atoms is just a field type, not content type!
You can have several Atoms-based fields attached to the node. In example, I’m usually using
field_headerandfield_content.And yes, Atoms are extremely powerful for custom static pages. But they are also very handy as a replacement for WYSIWYG-enabled fields throughout the Drupal site.
They allows you both:
You did not answer the question. :)
Easy: since this is just entity references you can output them in the view.
Two benefits here: 1) you can either output them as a fields attached to the node, and as a standalone entities 2) you can use custom view modes to easily customize the output.
That’s still not a proper answer. Of course you can list entire atom fields. But how can you list just the first image associated with an entity? Normally, you’d use an image field for that. With a WYSIWYG fields-like approach, you still could. With Atoms you can’t, AFAICT?
Okay, I will try to show the flexibility of Atoms in your scenario:
1) Create field_image of entity reference type pointing to atom:image bundle. 2) Now you can output first image in a view. 3) You also have default Atoms-enabled field_content and you can use fied_image in unstructured field_content since this is just reference.
Atoms give you a flexibility of WYSIWYG but keep the back references from layout to data displaying in this layout.
“the important part is that we ensure we are capturing the semantic meaning, not just extrapolating it from styling/formatting decisions.”
Just wanted to shout, “Too right!”
Thanks for the plug, Wim! ;-) This is definitely exciting stuff, and it meshes well with things we’ve been doing on client sites for a while now. Although we’ve been making do in D7 with tools like the Shortcodes module, or custom tags written for specific use cases rather than generic configurable tools, the results have all been very promising.
I spent some time chewing on the potential caching implications of personalization-heavy content in this sort of system at the last Drupalcon: Symfony may give us some interesting wins, since it offers a way to handle post-processing of page markup outside of the normally expensive Drupal bootstrapping process.
If you’re going to be at Drupalcon Barcelona, we should definitely get together and chat!
Yep, I’ll be there — let’s chat :)
I’ll be there too! ; )
Hurray! :)
Not going to lie, I’m a bit disappointed… While the terminology and usage is all fine and dandy, I honestly thought it was referring to a sites layout and adjusting accordingly based on the viewport requesting the site.
The same could be said for layout though:
Thing is, from the standpoint of the proposed model and the layout layer, the two could go hand-in-hand. By specifying the hierarchy of the content and making it self-aware, it could theoretically know where to go on the page without having to tell the theme to do it for you.
Themes shouldn’t be telling content where to go. It’s inefficient. The system that generates the content should tell the data and content where to go. It also opens up the door to coding for specific viewport sets and having separate code for each. This would also eliminate unused code from ever being sent to the wrong viewport.
Anywho, I was hopeful that the idea of separating the layout layer from the theme layer and making the layout layer become the powerhouse for website content manipulation was finally being realized. From the sound of it though, the podcast goes off into something entirely different.
Well, the title of this blog post explicitly states “structured” content. And “adaptive” != “responsive”.
I’m sorry you were disappointed, but the linked podcast (and this blog post) indeed solely cover content, independent of layout, i.e. semantical content.
I will say that your thoughts about a hierarchy of layout metadata does pique curiosity :)
I wonder if Jeff Eaton or Noz Urbina have some thoughts about this? I can imagine they’ve been asked something like this before. Similar concepts applied to something different (layout instead of content).
Hi Both,
What seems to be under discussion is the line between designing adaptive content vs adaptive design itself (See also a presentation on this topic). Adaptive design is a great thing, and far more clever than responsive design (which is a less sophisticated client-side shuffling of elements using CSS queries and other tricks). That said, I’m not a layout designer. I work with them, but I am a content guy through and through.
So, I’m sorry if the title was misleading, but basically if you see the “content” word vs “design” or “layout” that’s the differentiator I use to indicate I’m speaking about content issues and not the display layer (which I use as an umbrella term that refers to your layout layer and theme layer - basically everything that is in between the content and the actual display to a user).
The work I do is based on channel-agnostic (as much as humanly possibly) content, so the same content may go to print, or possibly to text-to-speech or augmented reality systems, so then many of the web-display issues become secondary.
I’m a fan of trying to aggressively minimize presentation layer information in the content. Remove completely is the goal, but sometimes you need to allow users to be able to specify certain issues like “This image is for high bandwidth, this one for low” because not everyone can afford to have a Digital Asset Management System in place that handles all that stuff for them.
If you have structured source content, then the display channels can (and IMHO should) ideally “pull” the content pieces it wants into the locations it wants them, rather than the content dictating to channels how to do layout (as Jeff has mentioned). The more layout metadata we put in the source, the more we restrict its adaptation. Adaptation to viewports and device formats is low-hanging fruit. We want a paradigm that supports that, but also contextual personalisation of long-form or bitty, field-based content/data using the same set of mechanisms.
Once you’re in a channel, then between preprocessing and final-delivery, the channel can do whatever it likes as far as I’m concerned. If we agree, great, but if not, I hope that makes my thoughts and message clearer and that they’re of some use.
Well, I ran across this post earlier in the day looking for some other info, had a whole big huge rant written up, then realized I had already posted and my rant would be off topic, so I basically wasted a half hour…
@Wim your interest in hierarchial content layout, made me think about it a bit so I decided to come back and throw a few nuggets out there to you.
Responsive as we know it, sucks. Even though every responsive framework out there touts “mobile first”, it is a lie. Responsive is nothing more than building for desktop, then shrinking down to fit a viewport. This is extremely inefficient in many areas but the two I would like to focus on are 1) speed & size 2) Lack of development targeting
Speed and size. With responsive, you design for desktop, which means you are vomiting every piece of code that is targeted at a desktop, all the way down to mobile. This bloats the code which makes for larger sites and in turn, makes the site slower to load on mobile. You may not notice it on a brand new iPhone with 40Mbit LTE, but in a third world country using 5 - 10 year old hand-me-down smart phones, it becomes a huge problem.
Targeted Development. Since Drupal (and the web as a whole) primarily develops for desktop first, (mobile first is a lie…) The JS libraries used are targeted to work on a desktop with a mouse. Until somebody complains to that dev and says: ” Hey, it doesn’t work on mobile…”, forcing hacky work-arounds to make it work on mobile.
So, imagine if Drupal were to pioneer a framework, that sat in-between the backend layers (DB, content creation etc), and the theme layer, and its sole purpose was to define and target specific viewports to handle how the backend communicates with the theme. Instead of a module being written with desktop in mind, it could easily section off to do various things depending on the viewport being targeted. This is one example. Another would be for a JS library to do one thing for desktop and something different for mobile, with the kicker that when a person views it on mobile, only the code necessary for mobile is being sent.
Essentially what I would envision is a framework that could build the entire twig template on the fly for a requesting viewport. Do away with static templates but if someone really needs and wants bare bones, hey, the foundation is there.
Content creators could then deal with the display of content on a granular viewport scale, and target changes to the viewport that needs it with the added benefitsnof a) not having to touch the theme and b) not sending fluff code that isn’t needed. A mobile viewport template, for example, could have all sorts of things stripped from it before it ever gets sent to the browser. Our solution today? Hide stuff with CSS… You’re still sending code and files to mobile that won’t be used by mobile but now the mobile has to decipher it and hide it through the DOM. Very inefficient.
We’re moving to an age where layout can’t be easily handled through a WYSIWYG because the content structures are becoming too big and complex to deal with. Try replicating product specifications to 1000 products in a WYSIWYG… On the other hand, data is also becoming so smart and dynamically driven, that the theme layer can’t handle it without a person constantly maintaining a list of CSS files for minor changes across viewports. Themes shouldn’t care about the data and the data shouldn’t care about the theme, but that’s exactly what we have going on with the current set of best practices. “Let the theme handle data it doesn’t know anything about.”
Technically, this approach is what I would consider to be a “True Adaptive” approach. I see a lot of frameworks that claim to be Adaptive, but they are simply breakpoint responsive frameworks. On the other end, you have fully segregated viewports, but each viewport requires the maintainer to deal with multiple sets of content for each viewport. I’m yet to hear anything from any of the respective web firms, talk about true adaptation to the device that is requesting the data. A single point of content with multiple layouts taylored to a viewport template that sends exactly what is needed.
Anywho, just some ideas to think about. I’ve decided I’m either way off my rocker or I’m thinking so far ahead that it will take another decade for the web to realize what’s going on and catch up.