 Today we're going to be talking about responsive content. It's a conversation of any time, just interrupt and ask a question. I'm a front-end developer. I've been thinking a lot about staying away from that speaker while I have a microphone in my hand, and thinking about responsive design from the front-end. But there's some really big implications for the back-end as well. I know the theme system really well. At DrupalCon, San Francisco, I gave a conversation, a core conversation about the render API and how complex it is. And what are we really doing here? And it was a bit hand-wavy, because I didn't actually know what was problem was. But today we're going to be talking about mobile. It's going to tie into WhissyWig, render API, design pattern, semantic, I think maybe I've listed everything that actually Drupal does. But that's a fantastic slide. Oh, right, okay. So what are some awesome things that you love? Chocolate and peanut butter, peanut butter cups. I love them together. They're fantastic. Ponies and unicorns, pony corns. Who doesn't love pony corns? The same thing is true about responsive layouts and responsive content, right? They really go together quite well. And Drupal's layout system makes it really easy to do responsive layouts, right? So you've got different regions on your TPL. All you need to do is apply some CSS basically, right? And you can have your regions sort of rearrange themselves. I think a lot of you are actually back-end developers. Is there anybody who's not familiar with this front-end concept of responsive web design? Because I could show another slide that shows what responsive web design means. Or did everybody- I don't know the term. You don't know responsive web design, okay. Right, so let me actually show you a slide that I gave at 1045 and make it really obvious what's going on, what I mean by responsive design. So this is a responsive website, Hicks Design. And as the size of your browser changes and like different devices, obviously have their own intrinsic width, you can see that the layout changes depending on what the width of your devices or what the width of your window is on your desktop. And this is a single source. There's no JavaScript. It's just HTML, CSS3 media queries, and some extra sort of CSS stuff. And here we're going to zoom out again. You see this is a mobile design, which is just a single column. And then as things are wider in your device, different things rearrange. So they fit into the context of your device. This is what responsive design is all about. And Drupal is great about this. You can do this right now without any problems, without any changes to the back-end of Drupal, which is fantastic. That's what I talked about at 1045. And let's go back to the other slides now. So I have pony corn. It's okay. There we go. Oh, that's too far. That's too much back. Yeah, okay. So another thing that's possible, and front-end developers are figuring this out, and again, we don't need back-end changes for this, because we don't have a node that has a whole bunch of fields on it. For example, you can create responsive panel layouts. So basically, you have a single source HTML inside panels. And you can add fields into this pane, and the other fields into this pane, and have the actual content be responsive in the same way that block regions in your page TPL can be responsive. So this is something that we actually just did at Palantir.net. Last week, and we haven't quite launched a site, it's probably going to be launched this week. And it's using responsive panel layouts to do content. And this works great with fielded nodes. Really, really great. The problem is, and I'm sorry I'm whispering. I totally killed my voice in my first session. But the problem is that there's a lot of sites that use the basic page content type. And the reason why they do this is because they have pages that they're not repeatable. It's not like you have another page which has the exact same structure. So you can't use fields, because if you created a content type just for that page, you would never use it. You'd have like one node, and you could do that. Some people do that for a home page. Adding fields to a single node or a single entity. Right. Sure, yeah. That might be a good solution. I don't know. But right now, basically the basic page content type is a single, it's a single big text field, right? That's the body field. And we always stick WYSIWYG editors on there and maybe you have insert module or media module or whatever so you're just dumping stuff in there and it ends up being hard-coded HTML inside your content, right? And so how do you... You can basically add some hard-coded HTML to do very specific responsive designs if you want to, but it feels like Drupal should have a way to make it easier rather than hard-coding HTML. What happens when you redesign the site, right? So we have to redesign all of these pages. Kind of stinks, right? So one idea that I had was... How many slides have we got here? I totally skipped a slide here. How did I do that? Let's bring it back to render API. So I really... I'm both frustrated by render API and I love it, right? Because Drupal 7 is super powerful. I can do crazy things because I'm probably one of the few people who knows that the whole system inside it out, right? Which is great for me. Not so great for everybody else, but... But render API is kind of like moonwalking in that it's very cool, you know, it helps you get dates and it's a really powerful dance move. But I can never tell whether or not render API itself is it propelling Drupal in the right direction? Are we actually going in the right direction? We're just sort of tweaked the wrong way so we're not actually looking where we're going. Or are we facing where we should be going and headed the opposite direction, right? So at San Francisco, I sort of just talked about the complexity of the system and the difficulty in making it work. And the thing is that the reason why we have render API in Drupal 7 is because we are lazy programmers, which is a virtue, right? We're lazy programmers. We needed a way to add more power to the Drupal 7 theme system. And we had this form API, which did a bunch of similar things. So why not reuse that code and sort of expand it and make it render API? And that's how we got Drupal 7, really. But that's because we were being lazy and just re-using code. But we didn't actually have any design goals of what are we trying to do with the system. And I think the end result really shows those lack of design goals. And when I started talking about responsive design, to bring this all back, I started to realize what my actual issues were with render API, which is that there's no design goals. What I sort of imagined is, wouldn't it be great if we had a wissy wig editor for this text area for our basic page, and you got to select design patterns. I need this images and then a description next to it. I need that pattern where it has three of those images and text and then maybe the image and the text sort of rotating back and forth. So you select that design pattern, stick it into the spot there, and then fill out the content. The design pattern itself is responsive. So that as you're going to different devices, it knows you can respond in an usual way. But the thing is that, that still gets us towards hard-coded HTML. And the thing is that we should be able to get the data out of that design pattern without necessarily forcing all of that HTML down of that design pattern for mobile apps that just need the data. Do we have to throw the entire HTML stuff down at the mobile apps in order just for them to sort of glean this information like the DrupalCon app just gets data? So how do we get this information? And the DrupalCon apps are great because they're working on field of nodes. There are no basic pages from the DrupalCon site that are in the mobile app, or maybe just a couple. But those have been sort of added very specifically. So if we could have some way for... How do I make the actual DrupalCon the content responsive? Let the theme system convert the semantic content. Understand the underlying idea of what is the content that I'm sticking into this basic page and convert it into a render marker for whatever I happen to need. If I need it for a website, it's fine. If I need it for a mobile app, it's fine. Any kind of device that we need... I know that Greg Dunlop who's not here right now, or at least he wasn't here, is working on this problem of Drupal needing to output all these different kinds of content and not just HTML. And our content from the basic page should be able to do that too. I'm just throwing out ideas here. I want to have a conversation and have people throw this stuff around. Is HTML5 to have enough semanticness inside it that it could be used as a sort of a general container and converter of understanding the semantic nature of our page to be able to convert it into these different formats? Do we need to have microdata, microformats, RDFA, whatever? I don't know. But Drupal needs to understand the semantics of what's inside what is essentially the giant text field that we ignore right now. JSON is a loose semantic structure. I don't know. This was something that was recently thrown out for the formatting of the... Yeah, the one with XML instead of JSON. But again, I'm just throwing out ideas right here. Please God, not at XSLT. This... I mean, that's what XSLT is basically for, but I just feel like this... It's never worked very well before. Maybe we can figure out how to make it work again, but anyway, that's my comment. And then Element Info API. Right now, in Drupal 7, there's an Element Info API that talks about different things, right? So in the render API, you specify that this is a list, right? And there's a whole API that specifies when you see that this is a list, you render it this way, right? And the thing is that right now, the Element Info API is very hard-coded to... I mean, it's flexible, but it's hard-coded to HTML output, right? And it's not thinking about things in a semantic way at all. It's just like, we've got lists, and I don't know what this means. We have an HTML tag Element Info right now. I understand the need for it, but it's not semantic at all, right? That's the end of my slideshow, apparently. I have no more slides. So this is when I wanted to get started talking about it, and I don't have good answers. I just have a whole bunch of questions. So have I, like, blown your mind or are you bored? So the thing is that if Drupal doesn't understand... Oh, yeah, sorry. So the question is he didn't understand what responsive... Right. He didn't understand how responsive tied in with semantic, exactly. And the thing is that responsive design is basically just a layout technique, right? There's nothing in it that's inherently about semantics. You're right. But the thing is that if we understand the semantics of our actual content in ways that we don't right now, except, like I said, for field of nodes, we're in good shape. We can add some sort of thin semantic layer on top of that and be racking and rolling. Basic page, we don't know anything about it. It's just a big blob that we ignore. We understood the semantics of it. We could transform it in responsive ways, not at CSS ways, but at the code level, back-end level, so we can transform it into these different things that we can't do right now. Right now it's just a big blob of HTML. Right. Let's see if I have... So you basically didn't understand how a content could be responsive or... How necessary is it to have the actual content be responsive? Basically, the more complex the content type is, the more necessary it is for it to be responsive, right? And then it's because you just... A lot of times when you have these complex content types, you're already doing fun things in the node TPL or whatever and moving different fields around and stuff into different wrappers, right? So you're starting the process of making nodes sort of responsive and that's only possible by hard coding the HTML for basic page content types. We can do it with the fields and things, but so it really is... Palantir.net, we were working on our own site to make it responsive and it's almost all content that's being made responsive rather than just like blocks and regions, right? So designers are absolutely going to need this and the thing is that I think that we'll need this same idea for outputting to different things besides HTML. Sorry? Context, yeah. Definitely. Drupal 8, so we're working on adding a context system into Drupal 8. That's absolutely required for this, right? Yes. Mark, Larry. I'm going to repeat the question for the video. So the idea is there's usability issue with when we were abstracting sort of the wissy wick basically, right? So instead of just like making things bold or italics or shifting off to the left or right, we have to think about, you know, semanticness about this. And the thing is that inside these, you know, responsive design patterns you can have semantics embedded in them and say that you need to, you know, or have a configuration maybe for... So you can say that these are the semantics of the content that you're going to be putting into this design pattern. And yes, there's going to be usability problems because you're going to make it more complex, but you're also going to make it easier if you have a good enough design pattern library, you're going to make it easier for them to actually create pages because they're not having to do all of it by hand, right? Because like basically when you have like complex HTML that you want to stick into the basic page, you turn off the wissy wick editor and you start typing your HTML, right? So how's it... Only in that I think that we should store the semantic knowledge of the content alongside any HTML that we're adding, right? So that we can understand at the same time, this is the semantics of it and this is the HTML that's sort of on top maybe. And when you're editing, you're editing sort of both layers at the same time, right? But it's seamless from the user. They're not editing sort of both layers, but Drupal understands both the semantic understanding and the actual HTML. Actually, it doesn't understand the HTML very much, but it would understand the semantics a lot better in the front there. What time is that session? Oh, okay. So there's another session right after this. You're watching the video. Watch the one that comes after. What's the name of the session? Did it help? Dita. Okay. So look for the video on Dita because it has some related information. Excellent. So the suggestion is that you use the documentation Dita semantics and sort of leverage that inside the responsive context. Lynn. So Lynn Clark was seconding what Larry said about adding complexity and there's an actual example of a media, semantic media wiki where they're actually doing something very similar to this and it adds just enough of burden that people don't adopt it. And the thing is that wissy wigs in general have that same burden though, right? Because as soon as you want to do anything reasonably complex, you turn off the wissy wick and then you write it by hand. So I... We do, but not everybody does. Well, yeah, okay. Right, right. Oh, yeah. And it's not an easy problem. But I don't think we should build like a system our own. I'm definitely, you know, investigate stuff and figure out what problems and avoid the problems or maybe improve or want to make them better. I don't know. I just want to start the conversation. So, yeah. Yeah. So the question was does it tie into this other idea of making fields so that you could like maybe just apply some fields to some nodes as an alternative to what we can currently do. Yeah, so the thing is that the basic page is not that it's... We're treating it as unstructured data because we're ignoring it basically. It's just a big blob, right? But it actually has structure, right? And I want us to be able to understand its structure. So, yeah. It absolutely ties into that, I think. If we could have like, you know, if we're adding fields into this blob, right? We should be able to track that, that it is this type of field, right? We don't want to just lose it as rendered HTML because the insert module I quite like, but that's basically the way it works right now is you insert an image field into the body type and as soon as you do that, it's lost. I mean, it's just rendered HTML and it never knows that it's a field again. Yeah, so there are two things here when you understand the semantics, right? So it allows a lot of different backend things that are not possible. And then, of course, the theme, the presentation layer, right, has to understand that as well. And the thing is that it's going to get some... From the backend, it's going to get some rendered HTML. Maybe it'll get different HTML depending on what kind of mobile device it is or whatever, but it still has to understand that. But it understands it in a normal way that it's always understood it. It's HTML, I'm adding some CSS. You know, we've got field wrappers right now. This is very similar to things right now, right? I talked about that, so the problem with responsive design that I absolutely agree with is that when you have these flexible columns, and the flexible images, what you're actually doing is actually downloading a big image and then rescaling it to be small. This is not particularly performant to put it nicely. Well, right, but some browsers do a much better job of resizing surprise, i.e., you know, older versions of IE don't... Actually, no, wait, it's not even old versions of IE. It's tied to older versions of Windows do crap jobs of resizing images. So if you're on, like, Windows XP, I think your images will look like crap no matter what browser you're using, and that's OS dependent. Right, and we're trying to figure out on the front end with some, you know, contrib modules, how do we do this so we're not hitting this double whammy of downloading an image that's too big and then also causing the mobile device to have to resize it. That's two hits against performance. We would like to avoid that, but we're trying to figure that out. That's related, but not really the same thing. Yeah. It's an issue of your problem. Actually, we're going to have a bof that will talk about this, I'm sure, because it's a big issue. At like 3.45, I think, that's going to be talking about responsive design in general. It's... I would love to talk for another like hour and a half, but it's 1.30, so I got to let end this. Thank you very much. I would love to talk more about this as anybody wants to talk more about just find me and we'll talk and... Yeah, thank you.