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

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?

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 adaptive_content module 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!

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?

What if you want to localize content but not layout? Make every element on the page an embedded item. Or copy and paste from language to language…

What if you want to reorder things on the page? Copy, cut and paste…

What if you want to know on which pages specific element is shown? Parse HTML…

What if you want a plugin for a list of abstract elements? In example you want Accordion and you want to place anything inside it. Implementing things like Accordion with custom content inside is really tricky with 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.

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:

If you have layout in your body field — other than perhaps “float image left” — you’re doing it wrong already.

Re-ordering things is only a common operation for landing pages, not for narrative content (articles, stories), because there the order matters for the narrative.

Yes, true. But the body field should only contain narrative content in the first place; for anything that is more structured, we use Fields in the Drupal world. (And that’s the beauty of what WYSIWYG Fields does: it allows you to continue to use Fields. But, I agree there are still many unanswered questions and a lot of remaining problems with how WYSIWYG Fields deals with that, such as required fields, field validation, et cetera.) Fields that are independent of the narrative should remain outside of the WYSIWYG editor, but e.g. an image field, that definitely could be integrated like WYSIWYG Fields does: it removed the need for content editors to go outside of their narrative and use this strange separate upload thing, to only then reference it again. It flips things around, by allowing the user to just upload the image, yet in the background have that populate the Field (and thus keep the highly structured nature, and the ability for e.g. Views to show the images for this entity).

Oh, yes, absolutely. I think an “Accordion” element has no place at all in a WYSIWYG editor. That’s very much presentation/layout and therefore shouldn’t happen at this level. What could be acceptable is for the user to embed (reference) an image gallery in the WYSIWYG editor, which Drupal on output (i.e. on filtering) then renders as an accordion.

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.

Content structure is hard coded in the markup. You could not say “I want to break down this section in subsection”, instead you say “This heading is <h3> which means this section is subsection of <h2>”.

You have to always edit the whole page.
You could not say “I want to break down this section in subsection”
In Drupal, we don’t build pages. We have content types, so that we can break up content in semantically sensible units (articles, talks, podcasts, products, projects … whatever your needs!). Your example of breaking things up feels like your content types aren’t granular enough.
Breaking up a narrative to make it clearer does not imply a single body field is getting in the way.
Yes, Drupal ships with a “Page” content type by default, but it’s only intended to be used for the typical handful of static pages like the “About us” and “Directions” pages.

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?

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?

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.

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!

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:

Structured - the base information

Adaptive - The predefined layout of the structured data based on viewport and determining factor on what gets sent to the browser

Intelligent - the data and content would be smart enough to know how to layout based on the requesting viewport.

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.

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).

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.