 All right, so this session asks a nice basic fundamental question. Is Drupal a CMS? A story in five acts. First off, my name is Larry Garfield. You may know me online as Krell. I'm a senior architect at Palinter.net, we're a web development shop specializing in Drupal based in Chicago. For Drupal 8, I was the web services initiative lead. I am also the Drupal representative to the PHP Framework Interoperability Group. We're just trying to encourage collaboration between a variety of different PHP projects. I'm an advisor to the Drupal Association and general purpose busy body. So that's enough about me. Act zero, because we're geeks, of course. Let's start with some history. We've all heard this statement before, right? Actually, let me start. Who here has been using Drupal for three years or less? Okay, yeah, three or fewer. Not you, Jeff. Okay, five or less? Okay, who here has been using Drupal more than five? Okay, this is the right crowd, then. So you've probably all heard this debate before. Drupal is an application. No, no, no, wait, Drupal is a framework. So, which is it? Is it a framework or an application? Well, it's both. We're a fram location. Whatever that means. I don't know. It's a framework-y thing application. It's just a problem. Why is this debate there? Why was this debate there? This debate has been around for as long as I've been involved in Drupal, which is getting on a very long time now, because these are different mindsets to think about this thing we call Drupal. Framework think. Framework mindset is concerned with things like why in the world is saving a node from code so hard? Why do I have to deal with making it into a pseudo form in order to do that? From a framework mindset, that is a problem to be solved. That is a problem that must be solved and that is a priority. And, oh yeah, the node form could be better, but really the problem is that nodes working in code is a pain in the butt. This is the important thing. From a framework think mindset. If you're coming at Drupal from an application standpoint, though, then a dashboard with widgets in Drupal 7 is important, because that's a feature that an application like Drupal should have. And that's a perfectly legitimate statement to make, that it needs that kind of functionality. But, wait a second. You want pieces out of this? You're going to reuse? Why? It's a dashboard. The priorities that these different mindsets have are very different and often conflicting. And for years, this debate raged through Drupal, through every issue and every discussion and every Drupal con. And somewhere around four years ago, there was a movement called Small Core. Who remembers Small Core? Okay, so this is old history for some of you. Small Core. The idea of Small Core was that the better Drupal becomes at being one specific kind of tool, one specific kind of toy, in this case a teddy bear, then the less useful it becomes for all of the other things we're trying to do with it. The better a teddy bear Drupal is, the crappier it is as a toy train. The better Drupal is as a bespoke, you know, out-of-the-box CMS application, the worse it is as an application framework, because the pieces are too tightly coupled in the application. And so the Small Core movement was very much a framework think approach. And the idea of Small Core was that Core should make fewer assumptions. Not that it's physically smaller, but the assumption list should be smaller. And fewer assumptions means more flexibility, more ability to use Drupal for different kinds of toys. It means looser coupling. Looser coupling makes development easier. Who was here for Mark Sonendom's session early this morning? All of the stuff he was talking about with unit testing. Loose coupling makes unit testing easy. Unit testing forces you to make things loosely coupled. These are both very good things, and they make development easier because you have less chance of breaking random things somewhere else. More flexibility means a better platform. It means a better system that we can then build on top of to build a site for a client. Build on top of to make a ticket tracking and project management system like OpenHGM. Build on top of to make a news aggregation service. And all these other wildly different things that Drupal is being used for. And by the way, as an example, we really need stuff like pole module and log module that are really hard coded to one use case. That's not really framework you think. This is a good example. And of course everyone fixated on that last one and no, that was not the point. Honestly, this is like the worst marketing ever from any effort in open source was calling things small core and talking about modules. Small core was never about removing modules from core. That was never the point. If you thought it was, I'm here to tell you you're wrong. Even Dries got that wrong in his core conversation in Denver last year. That was not the idea. The idea was that with loosely coupled components that we can rearrange, it's possible for us to then build a really strong CMS out of those loose components, out of that framework. Rather than trying to be a framework in an application at the same time and not prioritizing either one, ending up with this mud of an interface that tries to be a framework and tries to be an application at the same time and fails. Drupal up through Drupal 6 and some of Drupal 7. The way to build a better application, Small core argued, was to build a better framework first and then build the application on top of it. You have to build the framework first and then the application on top of it. Okay. These quotes are from 2009. Why am I still talking about this? I'm talking about it because we never actually answered these questions. This debate never ended. We just stopped talking about it. What has happened in the last four years? Well, symphony happened. One could argue that, great, we went the small core route and symphony is a big part of that. That's true, sort of, but that's true not because we decided that was the way we wanted to go, not because we had a consensus that we wanted to take that approach. We went because the people working on the core of Drupal 8 were stubborn people like me who took that approach and ran over anyone who disagreed. That's a very bad thing. To a large extent, I won that debate because me, Chris Vanderwater, Greg Dunlap and people like that who thought in a small core way were the ones doing the work. Not because anyone collectively agreed that there was no way to do it, simply the people who had the strongest force of will went that route. That's bad. That's not good. As the person who was victorious in that, in a sense, I think that's a terrible idea. That's very bad for Drupal. In part, because that was only one part of the picture. On the other side, this is that new note edit form that Dries was talking about as being this wonderful new creation. And sure, we actually have a wissy big now. We have this nice new interface on the side here. We actually have buttons down at the bottom explaining what publishing is. And that is great for the use case of a CMS. That is great for a particular type of application. But not for everything Drupal is being used for. There was a very lengthy discussion about this save and publish button. About do we want to force the concept of publication on our users? If you're building a forum, does that make sense? Do we even want to expose the concept of revisioning to them at all? Is publishing something that matters? We're forcing this into the UI to make it easier for one class of user. But that makes it harder for another. The site that got me into Drupal in the first place that I originally built out on Drupal 5 is currently migrating away from Drupal at my recommendation because of this. Not this forum in particular, but so much of Drupal now is so much harder to use than the general purpose framework. Drupal is a general purpose framework. The core system may be a lot more loosely coupled, but the entire package is much more of a CMS and much less of an application, every version. Because we never actually answered this question. The more Drupal becomes a better CMS, the less useful it becomes for all of the other use cases Drupal is currently being used to solve. Act one. So what exactly is a CMS? Well, it's a content management system, duh, which is a system for managing content. I'm still not saying anything. This is a quote from Daniel Jacobson, who coined the term COPE, create ones published everywhere. The goal of a CMS should be to gather enough information to present the content on any platform in any presentation at any time. Focus is on content on any platform in any presentation. A real CMS, a content management system, is just a content capturing tool. It is agnostic to how the content is displayed, where it is displayed, when it is displayed, on what device it is displayed. It is just concerned with managing and curating content. A CMS must be presentation agnostic. If it is not presentation agnostic, don't call it a CMS. It's presenting something. It's hard-coded to a given presentation. Then it's not a CMS. It may have CMS-type tools, but that's not real content management. It's a quote from Karen Regrain, who I really wish this session was being given after her keynote tomorrow morning, because I suspect she's going to touch on a lot of these issues. So everyone go to her keynote. By creating presentation-independent content that includes meaningful metadata, you set yourself up for a future where your content can go anywhere. Content and metadata. Structure of content. A CMS is a system for managing content and metadata. That's it. That's the extent of what makes something a CMS. A CMS consists of chunks of data and rules for managing it. Not presenting it, managing it. Now managing it is hard. This is a quote from Dean Barker, Gadgetopia, the Art and Practice of Content Assembly. It's a great article. I recommend you read it. Talking about content. In a CMS, you have to take content out of your pool and organize it and present it in different ways. Basically, that's Views Module, which is taking raw content and presenting it in a variety of different ways. Possibly different ways on a desktop website or maybe different ways on a mobile site or maybe in Drupal 8. We can now easily use Views to generate content out as a feed or whatever. This is a hard problem. There is no one single way of doing it. That's what differentiates different content management systems. Display of content is just a special case of managing. It is not the primary focus of a CMS. In Drupal, we have a lot of CMS-oriented tools, things like taxonomy, are structuring content and metadata. The entire field system where you set up your content types and you structure your fields in different chunks, this is CMS Think. It is Content Assembly. It is pulling content out and creating structure based on rules you define. The Rules Module is Plugable Business Logic that you are building around your content. The Panels Module is, again, building rules for the display of content. Not building display of content, building rules for the display of content. It's a very important distinction. The basic unit of a content management system is the content chunk. You'll probably hear Karen talk about this a lot. Act Two. Web Publishing Tools. What is a web publishing tool? Well, it's a tool for publishing on the web. It's really not helping. It's a tool for publishing pages on the web. It's a tool for publishing web pages. Web publishing tools capture content with the primary purpose of publishing web pages. They are presenting HTML tag to HTML tag on a screen. That's a web publishing tool. In the idyllic world, the archetype you're trying to go for is Dreamweaver in the browser. Maybe not Dreamweaver itself, if you don't like Dreamweaver, but that concept of I just want to edit the thing I see, and that's my content. That's how I'm thinking about using a system. And most casual users think in this way. This is what they think they want, is I want to edit a page. I want to edit the page, right? Is that really what they want? Well, maybe, but not necessarily. For that matter, is this just what we think our users want, or we think our users think they want, or whatever? Do we understand this problem space and do we understand what that actually means? We have web publishing tool type tools within Drupal, too. The edit module in Drupal 8, all that fancy inline editing that Dries was talking about. That's great. That's wonderful. It's pretty. It's easy to use, and it makes you think in pages. That is very much I am editing a page tool. Wissy Big, same thing. I'm editing the presentation of my content by shoving HTML markup straight into it. Modern Wissy Big tools do a pretty decent job of not generating garbage HTML, but you're still thinking in terms of font tags. Even if you don't have a font tag, it's still that mindset. Who's used the panelizer module? You can use panelizer in a very CMS-type way, in a very structured rules kind of way. But you can also say, I am going to edit the layout of this one page from HTML tag to HTML tag. And panelizer will let you do it, and you can do awesome things with it, and you can create custom blocks that show up on just one page, and then you can't really manage them. But that's okay if that's what you're going for. The media module. To my extent, if you're just using that as the fancy file selector for a file field, that's a CMS-type tool. If you're using media to plop images directly into the body of a text area using Wissy Big, that's a web publishing tool mindset. An awful lot of text filters are, again, based on this web publishing tool mindset. The Spark Initiative, which is responsible for things like Wissy Big module and Wissy Big and so forth. It kicked off a Drupal con Denver with this slide. These are things that we need in Drupal to make it really awesome, are real Wissy Big and inline editing, flexible layout tools, drag and drop everything, great media support, tight ends all that fun drag and drop, and oh yeah, I want to customize it for each device. This is a laundry list of web publishing tool functionality. This is very much thinking in terms of I want complete freedom to edit a page, not content, but editing pages and customizing for a device. I want to edit this page on this device. It's that kind of mindset. Want to edit pages, that is the core mindset of a web publishing tool. The basic unit of web publishing tools is the page. It's the page blob. Act three, when worlds collide. This really was driven home to me, this distinction of mindset at Bad Camp last year, where I ended up in a eight-hour conversation with members of the Scotch Initiative and the Spark Initiative. It occurred to me partly through this marathon discussion that ended at somewhere around four in the morning, as most good discussions do. The reason we weren't able to communicate, the reason we weren't able to all come to an agreement on what we should be doing with the editing process and with the curation process and so forth, is we were coming at it from two different angles. Some people in the room were coming at it from a content management, structured content and then presentation rules approach. Others were coming at it from a, I want to edit, a page approach. And these are fundamentally different world views. And I've seen this kind of distinction in the issue queues, in blog posts and so forth, just like the framework and application distinction. I've seen this creeping up on us as we're like trying to solve problems from completely different goals. We're looking at the same problem and we see different things that need to get done. And I'm not saying either of these is wrong, but building displays and building rules for displays are different things. They are fundamentally different problems to solve, different interfaces are needed, different skill sets are needed by the user, different tool chain is needed. The editing interfaces we offer, and this is why this is important, the editing interfaces we offer are affordances. If that primary editing interface focuses on a page and presents things as a page, users will think in terms of pages, they will think in terms of I want to edit the page. And they will think that is what I'm editing, that is the item, the object that is being edited is the page. And in some sites that's true. In some cases that is the right user model. On others, a page is simply a unit of business intent. It is a rule set for how to translate content into a display. Not something you're going to edit as one-offs, it's something you're going to edit the site builder controls, not the content editor. These are different things. Now, I want to make it clear. I'm not calling either of these worldviews wrong. If anyone comes out of this session and says that Larry said edit module is a bad idea, I will track you down and make you use nano for the rest of your life. That's not what I'm saying. Okay, you got that one. Good. But these are different approaches, different ways of thinking about this thing we call Drupal. Act four. So what exactly is Drupal? Where does the edit form go is fundamentally a philosophical question. And your answer to that question is going to depend on what your mental model is and what you think the mental model of your user is going to be. And that answer can vary per site. There are sites where you are going to be thinking in terms of pages, and that's okay. There are other sites where thinking in terms of pages is going to completely screw you. So is Drupal a content management system? Or a publishing tool? Is Drupal managing content? Or publishing pages? These are not the same thing. These are different tools. Is Page our basic unit of stuff? According to some of the people I talked to in the Drupal community, yes it is. According to some of the people I talked to in this room, no it isn't. That is a very big distinction that cuts to the core of everything we do in every single issue. We cannot be both of those tools at the same time in the same screen. That is not possible. That leads to the same kind of overly generic interface that is not good for anyone that Drupal was before Drupal 7. We don't need to answer that question now. I'm not asking people to come out of this room with an answer of Drupal is this type of tool. What I'm asking you is to think of this question as you're in the issue queues, as you're building sites for clients, as you're debating what kind of functionality should be in core and what should be in contrib. Every issue you're in, think about is the person I'm talking to, are we talking past each other because we have fundamentally different world views about what kind of tool we're going to be building here. The answer is probably yes, and that's okay. Your answer doesn't have to be my answer necessarily. If we're going to coexist in the same project, we need to understand where the distinction is and where it's appropriate to answer one way or the other. We need to understand and embrace both of these world views so that we can decide which one is appropriate when. It's not just a visual question either. As an example, in Drupal 8, we have this great new REST system. When you get the JSON form of Node 1, should the taxonomy terms on it be term IDs? Should we have the full embedded term object? Should it just be the string that is that term? What if the term has more than just the string name on it? You can even field terms now. What should that be? This is a philosophical question. If you're using panelizer, and then you can have custom blocks on a given page, or if the custom block stuff in Drupal 8 really goes where we expected to, then if you get the JSON form of a Node, should it include the blocks on that page? I don't know. Maybe. Does it matter if they happen to be stored as fields on the Node? We've got all kinds of stuff stored as fields that are really not content. There's a patch that probably is going to go in very soon that makes comment settings on a Node a field. So does that mean when we serialize a Node to ship as JSON we should include its comment settings? They're fields. But is that content? Or is that presentation? If you're using panelizer, where is the line between content and non-content? It's a very fuzzy line and it's getting fuzzier. We've all seen this picture before, right? Drupal learning curve. You know what really annoys me with this picture? I can name a thousand people whose learning curve in Drupal was flat, and they got awesome really fast. This is the Drupal learning curve for people expecting a web publishing tool hitting a CMS. It's not the learning curve of Drupal. It's the learning curve of people trying to use a content management system as if it were a web publishing tool. Think about that. What makes Drupal hard is not that Drupal is hard. It's that people expect it to be something else than it is. So do we teach them what it is, or do we change Drupal to be what they expect? Because those are two very different things and you'll probably get a few fistfights if you try to propose one as the absolute way regardless of which it is. Finally, Act 5. The last war. This is the section where I editorialize more. The last war was web publishing, putting pages up on the web. The internet is really good now at putting pages on the web. That's kind of commoditized. Tomorrow's market is where we should be looking. Drupal was talking about it as web engagement management, whatever that means, it's a marketing term. In order to do that, you need to think in terms of content. If I'm editing the page, I can't say on this page, change this piece here depending on the user. I have rules that control how the page appears that are sensitive to that user. We should play to our strengths. Any system, any project, any organization, any culture should play to its strengths. Our strengths in Drupal are as a content management system. Especially now in Drupal 8, with views in core, date module in core, link field, email field. Drupal as a content modeling tool is one of the best on the market. It's great. The amount of content modeling and real content strategy you can do with Drupal as your underlying tool is phenomenal. If you understand that you need to do that and that's what you're doing in Drupal, if you approach it as, I'm going to install Drupal and edit some pages, you're going to be very, very confused. People think in pages. It's just a natural way to think about things on the web because that's what we're used to. But when you talk about responsive design, where you need your content to completely redesign itself in CSS, when you talk about rest and serving out content through web services, when you talk about your content appearing in Instapaper where your design is just gone and all you're delivering is straight up text and maybe images. When you think about all the different ways that it's going to be presented, whether you want it to be or not, you have to think what kind of tools are going to support us in that. What kind of tools are going to help us think in terms of bits and chunks, not in pages? Is there such a system on the market that thinks in bits and chunks and not pages? That is really good at that. Can you think of any? Someone can. This could be Drupal. This is the market niche that we could totally poem. As long as we're able to articulate this distinction, not resolve, not have one side win, articulate and agree on where we're going to be one or the other, where we're going to emphasize what. The way to build a better web publishing tool is to build a better CMS first and then build that web publishing tool on top of it. If you want to have great easy editing capability that looks at a page, fine. You still need to have that good structure underneath so that you can do anything at all with it. Build a CMS. Build the publishing tool on top of it. Build a framework. Build the application on top of it. Think and layers. Some further reading. I highly recommend all of these links. I will be putting these slides online and tweeting it later, so you don't need to write them down now. A small core manifesto was one of the basic statements from the small core initiative. Where do we go from here? There's my entry into that debate. Drupal is not a CMS. There's a different article I did last year. Again, looking at this structure versus bespoke system question. Daniel Jacobson's Cope article. Greatlands published everywhere. Content strategy for mobile by Karen McGrane. It's a fairly short book. I recommend it for anyone working on the web. Adaptive content management by Mark Bolton. Jeff Eaton, read over here. Inline editing and the cost of leaky abstractions. And then, is Dean Barker actually in here? Did he make it? Yes. But he has some excellent, excellent articles on the subject of content management. In particular, content geography and the art and practice of content assembly. I do recommend both of these for anyone who does anything in Drupal. This debate aside. There's probably more, but there's a lot that's already been said on this front by different people that is worth looking into. It's worth seeing a lot of this debate has already been happening. And before jumping in, try and get a sense for the different perspectives and try to appreciate all of them for what they are. And don't look at it as right and wrong. Look at it as different perspectives on the same problem. How can we make them compatible when they are not automatically compatible? Discuss. You need to come to the microphone here. Please talk loudly so that it gets recorded. Ladies and gentlemen, Jeff Eaton. Thank you, Larry. That was awesome. Do you really think that Drupal can't be both? And if you do really think that if it was going to divide into two layers, would you see that as being two separate projects? It can't be both at the same time in the same interface. Just like framework versus application, you can have a framework and an application in the same repository as long as you still have the individual pieces. Good example there, a nice little small example. The machine name field. In Drupal 6, if you had the text fields put in the name of something followed by an auto-generated machine name version of it that you could edit. There's something custom you had to write. Writing that custom each place is done. In Drupal 8, I think, that was added, there's now a form field for that. That piece of application functionality has been turned into a piece of framework functionality the application can leverage. It doesn't have to be in a separate project. Some projects are doing that. Joomla, for instance, has forked their system into Joomla CMS and Joomla framework. I don't think that's a good idea, but I think that's a good idea for Drupal. In terms of CMS versus publishing tool, as I said earlier, if you're going to do both and you want to do both well for the modern web, the CMS has to be the lower level. You can build a publishing tool and publishing workflow on top of that, things like edit module or even fancier rich text editors, but the underlying system has to be fundamentally a CMS structure to be able to build a customized publishing tool for a given client. The publishing tool that fits this client and the publishing tool that fits this client are completely different animals and building a system that lets us customize Drupal for one or the other means having that CMS foundation first. I'm not suggesting we throw out the web publishing tool parts, not at all, but we layer these things appropriately so that we can do both in the right places. In summary, I think what you said correct me if I'm wrong, is that yes, we can do it in the same project, but we need to be more conscious about the layers in what goes where. We can do it in the same project, not in the same screen, not in the same workflow, and that is something that's going to be very hard to understand, that you can have one project with multiple layers of workflow in it. That's a very hard usability problem. I'm not going to sugar coat that, but that's where we need to be putting our energy to deal with. How do we balance them? How do we deal with them together in a way that's not going to royally confuse everybody? Thanks. Hi. I really enjoyed your presentation. Thank you. My question to you is, and I guess it's a question and a comment and a couple of ideas of my own at the same time. Ideas of your own are exactly what we should be doing for the next half hour. You had a slide up there that said building displays and building display rules which are different things, very different things, but without either one of those you can't build a display successfully in any meaningful way. So what struck me as good is during your presentation you separated this quite a few times, which is absolutely fine. However, somehow I missed in your presentation the next step of this, the next logical inclusion is that those are two things that are mandatory to make something better. So this is the thing that I kind of like miss. So yes, it's obvious that those are separate things but they have to come together somewhere. I think Drupal does an okay job of using these together. It can be better. It can be easier in some places, but still, it's the glue that does bring them together. Another point about information, whether it's a common management system or how do you present a note? Do you present the blocks? It's very philosophical, but you have to very clearly understand and explain to yourself what makes up your smallest unit of information possible in your particular case. And in my opinion when you say do we display the page with blocks I know we don't. It's very obvious to me that most use cases there are some probably cases where you do want to display pages with blocks, but most use cases you see on the web right now and in the web publishing world in general your blocks or side notes or right rails or left rails whatever you get on your web pages contain helper information, related stuff, but if we talk about stuff like feeding information out of Json Theater or whatnot you want to present pure information. You can build an API or a service or something on top of it that will allow you to pull in additional stuff but at the core it should feed out your smallest unit of information possible. Thank you. The thing is your smallest unit of information possible is an easy answer. It's not an easy question to answer. I would agree, you just serve the node but I did a site last year where we used panelizer and every page could be panelized and have a completely custom block on it. So if they were to start offering that as you know as Json for some reason should we include that? What is the information, architecture and that is a site-specific question and so we need tools that will support that. I'm also going to something you said earlier that you have to have both of them not actually. If you have a tool like say Alfresco it's just doing content. It really doesn't do web publishing as far as I know. It's just managing binary content and assets. But you need to present the information whether it be for render, HTML or Json is also presentation information. But on the other side though say you're using Jekyll. You can put up web pages with Jekyll. You're really not doing any kind of content strategy there. You're writing markdown and generating HTML off of that and it's a completely legitimate way to build a site. But I'd say that is not a content management system. There's no content management involved there. It's just a presentational tool and that can be okay but then you're not going to be using Drupal anyway. Thank you Larry. It was a very good presentation. I like the separation of concerns between content management and presentation but just one question I had is that suppose we are in this ideal world where content management is isolated and we have these two separate distinct layers then where would the content authors go for editing the content? Would they go and edit the unstructured content and we would somehow decide which structured content it maps to or the other way around? I don't know but that's exactly the question we should be asking with this mental framework in mind. That answer may be different on different sites and we need to make it easy for the person designing the site to change their mind and do something different than what we assumed. Is that the distinction that the CMS is dealing with the structured content and the WPTs or web presentation technologies is dealing with unstructured content? I think that's a little bit of an oversimplification but essentially yes. A CMS is concerned with that structure and a publishing tool is concerned with the way it looks. It's concerned with the page. So is CMS just a little bit higher level than the database? It can be a lot higher level than the database. It's a higher level abstraction on the same data. It's concerned primarily with data not with look but with view. Thank you Larry. That was a great presentation. I'm responsible for a large installed base of Drupal 6 sites. Mostly we're starting to upgrade to 7. It was used very much as a web publishing tool. Oregon State University. Looking ahead I realize I'm not going to get this all upgraded to Drupal 8 because it could be years. But I'm looking at Drupal 8 saying I could use that back in for application development. Don't even worry about the front end. I'm not going to give that to users as a web publishing tool but I've got a lot of content that I need to model. I need to get that in database structure and I want to use Drupal 8 for that. Using services in CoreNow it seems like the perfect back end for applications that mobile applications even older Drupal 6 and 7 sites consuming that data but using the strengths in Core as the content management system. Just to let you comment on that. So by way of answer I'll say I've got a project I'm working on right now at Palence here and I'm not sure if the client is yet because we haven't launched. We're ingesting data from the third party feed of theirs doing some content curation and management and workflow within Drupal and then serving out over how Jason how for client applications and I looked at the spec and said wow Drupal 8 would be the perfect system for this. To be honest I can't use it yet. So at the moment we're actually working on the third party then we're dumping it into Elasticsearch and doing some processing there and then serving it from Elasticsearch using Psylex which is another symphony based micro framework. That's working okay there but the idea of a lot of the stuff we've been doing in Drupal 8 is not to have to bridge out to a third party system to do that so we can do that all within the one system and again that does require having a third party system. If you're looking at migrating to Drupal 7 now and that's something you're thinking about save your budget for one year and do it in Drupal 8 next year. Talk to me afterward I've got business cards. Hey Larry I guess it's one of the things that struck me first of all the comments about getting people out of thinking from a web publication system to a content management system really resonated with me. I took at least one client through that kind of revelation and it really changed the way they did business for sure. One of the things that strikes me about as you said it's really clear that the edit module is solving that sort of core publication interface need. Are you aware of or can you speak to the really efforts out there to solve the really hard UI challenge of getting people to think about how they organize their content from the content management perspective in terms of or do the do this. Pardon? Come to our sessions in room B13 after this. Jeff Eaton who's one of the loudest content strategy voices in Drupal I don't know of any particular interfaces that are really good at teaching people content strategy if you know of any I'd love to know about it myself really and if you have ideas for them if Drupal could do that probably at that point in Contrib or in Drupal 9 seriously that's market shifting awesome right there. Probably very few people here know me but I was the maintainer and the person that ported NodeBlocks to Drupal 7 and NodeBlocks came out of the necessity to obviously overcome the shortfalls of the block system feeling to have fieldable content and so forth and so moving from Drupal 6 to Drupal 7 the big idea was to make everything entities everything was field driven use the same system across the board but I find now with Drupal 7 one of the biggest drawbacks is you want the benefits of say a node but you also want the benefits of what would be a taxonomy and so forth I was kind of curious from you what your thoughts were on this in terms of say the revision system right now that's primarily drawn towards nodes but would be very useful for block entities or taxonomy entities they all have that common ground getting away from the whole concept of nodes are always pages but they might be used kind of elsewhere as teasers whatever it may be taxonomy is always categories like instead making those more interchangeable pieces versus do we just have these defined so I'm actually going to disagree with the people cheering back there I do I do think there is value in having different types of entity that have different fundamental behavior because they do different things users should not be nodes they're fieldable that's fine it's an extensible data structure but they they have different business logic that's appropriate to them nodes of a different business logic terms of a different business logic I'll say you probably don't need to port your module to Drupal 8 because custom blocks in core is fieldable so node blocks you're off the hook now I appreciate it I think you owe Chris Vanderwater a beer for that but yeah there's certainly when we separate out pieces properly and look at the domain models properly then we can often see a lot of places where oh this would make sense over here and if we did it this way it would be a lot easier to do over here revisions being one example there are probably plenty of others I think were you here for Mark's session earlier? okay sorry published publishable is a thing that we could easily spin out and share between different types of entity without saying everything is an entity of the same type and I think that gives us a much richer data model and a much richer business model to work with yeah yes that's that's my commentary just a quick follow up is there a good place to jump in we don't really have a good place online for this level of existential question the reason I'm doing this session is because we need to be thinking about it and figure out where we can have these existential discussions so if you have a good idea for where we can have them other than this room please let me know we're wearing my Drupal Association advisor hat if there's a way we could make Drupal.org better for that kind of discussion without it turning into a bike shed I'd love to hear it I don't know of one but other than that Drupal is kind of where that sort of conversation happens so thank you so I want to say it was a great presentation I like how you're broken things down into getting people to think about a page not just a page it's blocks various different things that are going on one of the things I want to post to you is have you thought about how some of the ideas and concepts that you're talking about apply to parallax web design and you see a lot of WordPress parallax it's basically responsive websites which is the latest trend that you know shows up we talked a lot about it and parallax is basically a scrolling format where the site doesn't actually resize but you scroll it somewhere to so you use on an iPad if you go out there Google parallax you can see a lot of people talking about it and there aren't very many themes out there there's WordPress themes that people are selling that adapt to the parallax concept so these are like the ones where each page in a series is actually yeah that's right everything seems like it's just one page in the content conceptually is in one page and a lot of things you're touching upon would apply to trying to implement something in parallel implement a parallax design in Drupal but nobody's really doing it yet and I was just wondering if it's come up or have anybody talking about it I'm not aware of anyone doing that kind of design in Drupal I'm not a designer but my impression is if you're going to do something like that you're going to do it as a one-off you're going to do that as a content presentation mixed thing and then you're going to think about it in web publishing tool terms because the page or the long page scrolling page is your basic unit and for that problem space that's okay trying to do arbitrary nodes shoved into a view to give that kind of presentation is probably a bad fit so in that case you want something that's going to really support web publishing tool capabilities rather than a content management system it's a different type of problem space in a different tool hello I'm clearly much shorter than everyone else in the room so I have opinions about CMSs and things because I am a content strategist so I never get to use Drupal I'm sorry and I'm going to tell you why I never get to use Drupal and I'm hoping that part of this conversation will be something that we can look to fix that the reason I never get to use Drupal is it's very hard for me as a content strategist to demonstrate to people the things that I know Drupal does really well in terms of managing content and some of the stuff you're talking about in terms of stripping things away from pages and putting them into units that can be bolted together come to my presentation and so I would really like to know how here's the situation I face as the content strategist I generally get to make a decision about what CMS we're going to choose and usually the last decision lies with me right up until it becomes a money thing now with Drupal that's not too bad because I can say well the developers are pretty cheap compared to buying in a solution and we can get it to do pretty much anything we want but I have no real way of demonstrating that to people without having to go through that setup and so I can't demonstrate what's good about Drupal in terms of that manipulating values of content to do what I want to show that you can strip it away from the page so I guess what I'm looking for and one of the reasons I came to Drupal is to find out what plans there are to make it easier for people like me that are not developers to demonstrate what Drupal does really well and this seems to cross over with that in terms of is it a CMS or a web publishing tool I'm looking specifically for a CMS or a web publishing tool how do you sell the CMS aspect for people who don't realize that's what they need yeah I guess a little bit but specifically about Drupal because I can sell CMSs till the cows come home but specifically there's no way of me doing that with Drupal very easily so I don't have any specific effort at second point too I can give you some ideas Drupal 8 has a new tour module that I have not played with but it might be possible to build that will take you through some kind of pre-built site that shows you edit this thing, edit, edit, save now it shows up over here, magic so something like that where you can actually put someone down in front of it and say here's this thing years ago there was a site that had a bunch of different CMSs pre-canned that you could just push a button spin up a version that lasted for like 5-10 minutes I think that died I guess that was only at that point would have shown any of the desktop site and what I really need to do is to show that Drupal can handle the desktop site a mobile a tablet, a one inch watch, a 50 inch screen you know if you can pull off a one inch watch and a 50 inch screen of the same markup I would love you I'm more talking about the same content than I am the same markup which again, there's that that's exactly what I'm talking about, that extraction and other than building some sample implementations to show off that distinction and letting people walk through them I don't really have any good ideas for that my strong recommendation would be that someone gets on that because it's the thing that really means that I struggle to sell Drupal even though I know it's usually the best solution for what we're going for I end up with something that kind of does that but I can show that it kind of does that and that's what at the moment in terms of day to day work that's what my clients want to know and they want to know how am I going to make this content display on 60 different types of things I'd love it if I could get you talking to the people at the Drupal Association in charge of marketing because if we can get you to get them some ideas for how to make marketing videos that target that exact question that would be great so let's talk after the session as usual I love your analysis and I like your insights likewise it occurs to me just in terms of first impressions that the debate or the discussion as you've posed it CMS versus web publishing tools is similar to something which I fond of talking about which is outside versus inside so from a usability point of view I strongly advocate for an outside-in approach to analyzing those problems and solving them and it seems that the terms of reference that you've put here correspond to that in that the web publishing tools does really map to the world of the outside the CMS maps to the world of the inside and the reason why I think it's useful to look at that point from that point of view is that clients, all the clients I've dealt with are on the outside they're all out there looking at the screen thinking that the screen isn't the website we know differently but that's how they see it, that's their reality so the whole point behind the concept of a web page as a unit of business intent is to somehow allow discussions to take place with those clients about their needs and what their intents are for their websites and have that somehow tunnel in to the inside with useful information about the rules of content management and how content should be managed so it's interesting that it's still consistent with that point of view and the one other thing I just wanted to mention is that the mediator between I don't think you mentioned this but the mediator between those two worlds I think is still the site builder the site builder is the person who will configure the rules and create choices the right sort of chunks of things that then become items of discussion and planning and intent for the outer world with the client I just want to mention that I think that gets to the bridge I see this question is do we try and build a better web publishing tool interface or do we try and build an interface that teaches people how to use a CMS if they're expecting a publishing tool and I think that the second one of an interface that teaches people about a CMS as we're using it is much harder to do and also a much much better approach and a much better tool in the end if we're up to that challenge and I would like to think we are it's just a very hard problem it's a worthwhile problem to solve yes it is so sorry I don't use these too often my name is Jay, University of Lethbridge in Canada I enjoyed listening to your insights so I think I found myself disagreeing with the number of them I'm hoping that if one of those epic 4am conversations happens this year if anyone should happen to see me in the hallway let me know I'd like to take part they usually involve beer they're still involved beer anyway if you see me I'd be happy to chat thank you all for coming let's keep this conversation going and I'm about to head over to the day stage let's talk about Drupal 8