 Guten Tag! Espreche kind Deutsch! Presentation Alf English! So, I'm Emma, better known as Emma Jane. Emma is my muggle name. Please feel free to use whichever one you're most comfortable with. I wrote a book a while ago called Frontend Ruppel. Yes, there is a new version coming out soon, soon. And I'm also operating as a company called Design to Theme. I'm based out of Canada, so this presentation will actually be in Canadian, not English, and I think this presentation is a, for me, a really interesting one, because I think that it, base themes are ultimately pretty misunderstood. So the agenda for today has morphed a little bit from the original version of this presentation. We'll start out by defining what I think a base theme is, and it will perhaps be the same definition that you're used to. I will then go through the, as promised, scheduled presentation, where I do an evaluation of some of the more common base themes, and then in the last little bit, I will go off the handle and rant about the developer experience for front-end developers and ask the question of whether or not we should keep the folder called themes in Drupal 8, or whether the web has simply outgrown this concept. So the the last part, I have to admit I'm a bit nervous about, because it is a radical change from where we are now, but everyone that I've talked to in the professional theming community has looked at me, rolled their eyes, and said, well, thank goodness you've finally gotten to the same conclusion. So hopefully it will be a welcome addition to the talk. As I said before, I think base themes are misunderstood too often in the PoundDrupal-themes channel. I hear people come in who I'm guessing are relatively new to Drupal, and they say something to the effect of, I'm looking to upgrade my site from six to seven, or coming in from somewhere else, should I use Zen or Omega, and that's the end of the question. There's no context about their skills, there's no context about what they're trying to accomplish. It's simply this little this little nugget of joy that's dropped into the channel, which almost always results in a not a conflict, but perhaps a spirited discussion from community members over whether or not the Zen framework is better than the Omega framework, and it doesn't, it's not always very productive. So I'd like to go back to the definition of these two words. I'm going to start with the word base, and the base, I'm not sure if you can actually read any of those words, it's when you go to Google and you say define colon, and then the word base, we're basically looking at the lowest part. This is the foundation that we will be building on. Later on there's a quote from from John who's in the second row over here to my right, which basically says a base theme is complete when there's nothing left to take away. It's what you want to be building on top of, but there's definitely nothing you need to take out of to make it work. The next part is the theme, and the theme is sort of the the cluster that we would normally think of as if you're in, how many are designers, because I'll probably offend some of you at least twice. Okay, and how many people are very joyfully clueless about design? Great, and then there's probably a few in the middle. So theme, I'm going to call for today's presentation and design. I'll refer more to decoration, because ultimately as themeers, it's our job to take the designed-based solution that our designers have provided and converted into a Drupal website. But for the most part the technical bits that we're implementing, the decision-making stuff from a design point of view is finished, and we're working merely on decorating at this point. So the theme is what do these three buildings have in common? They have a theme, they have some paint, they have a little bit of specialization in terms of the color of the door, but ultimately they look the same. And when we think about base themes, yes we are starting from a point of the base theme looking in common, but what we shouldn't have... Oh, where's my slides? I apparently moved one. So what we shouldn't have is a base theme that tries to actually design our site for us. And what we too often find when people start theming is they start with the base theme, what they think is an appropriate base theme, and then they start ripping things out, because it's not quite what they wanted. So this is a picture that I discovered when I was renovating my house, and right in the very center of the picture, what you can't see is a structural post that's had a unit cut out of it, and a 2x4 has been nailed to the outside of what used to be a structural post. And too often this is what happens in theme land where we have a workable base theme, it's not right for us, and so instead of choosing a different toolkit, we simply rip out some of the fundamental parts, some of the most important parts of that base theme, and then try and tack new stuff on. If you're doing this with your base themes, you're doing it wrong. You've picked the wrong base theme for you. Ultimately, when we're working with Drupal Core, we're working with a series of overrides. And at the theming layer, for the most part, all we're doing is overwriting what some four-module developer thought was a great idea three years ago. So we'll be on this presentation focused on the outer parts, on the blue, the base theme, and I won't be referring to it very often, but your theme sits on top of that. As we get progressively closer to Drupal Core, we've got our templating engine, which for the most part is PHP template, but maybe switched to twig for eight. We have our theme system, which is an API and an ink file totaling, I don't know, maybe it's about 3,000 lines of code, someone probably knows that answer. And then we've got Drupal Core itself, and I haven't even talked about contributed modules, but it's a series of overrides. And if you're starting with the base theme that you're already having to rip a bunch of stuff out of, you've got enough stuff to worry about as it is. As part of my presentation, I looked at a lot of the comparison charts and also worked on my own comparison charts. And I came to realize that these comparison charts weren't really doing us much favor. And that's why we had people coming into the IRC channel and saying, is this, you know, should I be using Zen or should I be using Omega? And in my mind, you don't get to compare those two. They're not, they're not in the same circle. When I looked at all of the more popular base themes, I came to realize there's a sense there are essentially three different kinds of base themes. There are base themes that adapt Drupal Core's markup. There are base themes that adopt outside technologies. So for the most part, CSS Grid frameworks. And there are also base themes which essentially annex or bring together many different kinds of things. And for me, the, the annex base theme, skipping ahead, let's go patiently through these. The adapter base themes are striving to improve Drupal's core markup. And for the most part, when we think of an adapter base theme, or if we're going to be using this new definition, we're thinking of the Zen's, the Boron, which is the HTML5 version of Drupal Core and also mothership. They're not bringing in any new technologies, they're simply fixing what's there. And one of the interesting things for me when Zen came out with ZenGrids is that it kept it separate from the base theme. You can pull it in, but it's a separate entity, which is why it remains as an adapter theme. Adapting is like doing a renovation of your house. You're essentially keeping the same structure in place, you're just fixing it to make it work a little better for you. The next one is the adopter section. And in the adopters, we've essentially got some kind of non-Drupal technology that's being pulled into the base theme. Right now, it's typically CSS grid frameworks, but there's, there could be other things in the future. There's no module to install. It's simply a set of files that exist. So it could be either JavaScript, jQuery or CSS by my definition. And here we're looking at things like 960, SquareGrid, Blueprint, name your favorite CSS grid framework here. Adopting is like buying a house. You have the limitations and the potential when you get that new building, but ultimately it's, it's one single entity that you're bringing in and it's shiny and new and very exciting. The next one is the annex. And this is, it was mostly the alliteration, but the word annex actually fits here. Because you've got a concept that's growing out and pulling in all of these different things, but under its own brand. So although Omega uses the 960 grid framework or started out with it originally, it doesn't try to adopt it into its name. It simply assigns a new name to it. With this definition, we're also going to say that we need to install at least one set of modules. So with Omega, you've got the, is it Omega Tools, Fusion? You've got Fusion Accelerator, Adaptive Theme, G-Panels, but you're, you're adding something else. You're adding some kind of functionality. With these ones, I think we also start to see what I, what I have come to, not in a negative way, but what I've come to admit is more of a WordPress approach to theming, where you're essentially getting an entire install profile and a new way of thinking about your site, but at the theme level, and in our case in the themes folder. The annex is a neighborhood in Toronto. So whatever definition or whatever connotations you want to give to the word annex, you can think of it as a neighborhood. This isn't a single house. This is a collection of houses. It's a collection of families who all have their own problems that you're going to be bringing into your own system. None of these, however, are a base theme that tries to decorate your site. You're not getting a pile of building blocks that also come with color. Yes, you get some regions in place, but it's not meant to in any way define the visual aspects of your site. For now, we're going to be ignoring the workflows that aren't using base themes that fit into one of these three categories. So for example, we'll be ignoring base themes that are starter kits used by, for example, a university department, which does have branding in place. So if the head of the university has said, this is our starting kit or our base theme, you keep the colors, but you're welcome to adopt the banner, change some of the navigation, those kinds of, we're going to ignore that. We're also going to ignore the workflow whereby you start with no base themes. Both of these are absolutely valid approaches to theming Drupal, but for this presentation, I'm really interested in what's happened in or what have we created in the base theme ecosystem and then what does that tell us about core? Because really, these three things, I think define most of the base themes that we have come to work with, appreciate, acknowledge, and that NX1 makes me a little bit concerned. Concerned in a good way, but also in a way that I think with Drupal 8, we've really bumped into some limitations and we've started putting functionality and non-base theme-esque stuff into the themes folder. What it does show us, though, is that core is really flexible. The fact that we have these three different starting points and we can grow and as a community, I mean, we love to have our little arguments about whose theme is better, but we acknowledge that they're all valid starting points for some people. We can swap them in and out. Thank goodness we didn't put the 960 grid framework into core. We waited. The web changed. We can swap stuff in and out. I think that this is really healthy and it's good, but it's also showing us the core is broken. That's where the NX themes are really, they're really showing us our limitations. The fact that, and I will acknowledge the Drupal 8 work, that's happening, but ultimately what we're seeing is that theming kind of really sucks right now and the workarounds that we're developing, we're spending a lot of time in theme contrib, but maybe that work should be going into core as well. Maybe we need to completely rethink the problem. There's definitely something that isn't working. This isn't just about whether 960 is better than blueprint, is better than square grid. This is a different kind of problem. So where do you start? How do you actually figure out which is the best starting point for you? Now that I've broken it into those three categories, some of you may already start to recognize what feels most natural to you, but it's not really, I mean you see now where I get frustrated when the Zen versus Omega question comes up because they're different. They do different things, but you still have to decide for yourself what the starting point is going to be. When we look at base themes, how many people are working as a solo developer? Let's start there actually. So solo, you do the site building, the theming, the everything. Just maybe 10, 20, 30%. And how many people work as part of a bigger team? Good because that's the balance of people. Sometimes they're not the same. So when we talk about our starting points, we're ultimately looking at not just our own skills. So skills in this point could be do you know HTML? Do you know cascading style sheets? Do you know jQuery? What are you personally able to accomplish? What are the tools that you're working with? So for example, have you decided that you want to be working with some kind of CSS preprocessing tool, whether it's smacks or sassy or sooty or whatever the, I don't know them all. But what's your toolkit? Is it GUI based? Are you more comfortable with a point and click UI or are you more comfortable at the command line? And then what does your team look like? Are you actually needing to integrate with another team? Because if you are, you'd better be able to push those configuration options out of your theme to be able to share them with your teammates. So that's kind of your starting point. And only you can answer those questions. And if it's a matter of writing out some notes and saying this is where I am today and therefore this is where I could be tomorrow, that's what you need to do. But I can't answer those questions for you. The next part that we really need to take a look at is what happens when we deliver the website? So of course, as a former web standards team member, I don't know if you guys know the WASP project, I love semantic markup. However, my clients have never paid me to deliver a semantically valid website. So some of the stuff that we as developers like doing, we like the technical challenge, we like the elegance and the beauty of these things, they aren't necessarily what we're being paid to deliver. And that's where if the community of volunteers in terms of the Drupal community is interested in taking that and putting it together as a base theme, by all means take advantage of it, but look carefully at what you're being asked to deliver and then reconsider and not change your mind, but reconsider, am I choosing the best base theme for what my team or myself as a solo developer has been paid to do? The next part is phase two, and this is where, great, you've delivered your website, congratulations, the web is not print, it will get changed, and is your client the kind of client who wants to make changes on their own? What's the business model that you have for your company? Are you wanting to be paid on a regular basis for website maintenance? How many people think that's awesome? Okay, there's like two of you who are willing to put up your hand. Most of us are like, move on, thanks very much. So consider how this website is going to be maintained, and if you have a technically savvy client, they may actually really enjoy using one of those annex base themes, which gives them the opportunity to point and click and change the configuration, change the layout of their site. All of the designers just cried inside, but it is something to consider. So these combination of factors, your personal skills, the tools you want to work with, the team that you're working with, and the workflow that you've established with your team, what you're asked to deliver by your client, and how your client is going to use the site in the future or grow the site in the future, all of these things will shape the decision on which base theme is most appropriate for any particular product that you're shipping off to a client. And that's where deliverables in phase two, you may not use the same base theme for each project that you put together for your company. I've got this one up here because I think that teaching theming has made me cry inside a lot, but it's one of those things that I've come to see that there's a progression that makes sense for my students, and for my students for the most part, when they come to Drupal land, they don't know web technologies. And I have to say that I'm really glad I learned HTML in 1996. There was a lot less to learn. And for the most part, I was able to keep up with the progression of changes over time. If you're coming into the web today, there's a lot of stuff that you're being exposed to. And so the progression that I go through with my students is similar to the progression that I went through from 1995 to today as a web technologist. So the first thing that I teach is layout and markup. We work with big containers, big shapes. When I'm teaching this in Drupal land, I tend to use an adopter theme. My personal favorite is 960. I'm not also fighting with responsive design at that point. I can simply say to people, you've got 12 columns divided up into smaller sections. The reason why I do like 960 for this is because my choices are either 12 or 16. There's not 30 columns or 35 columns to subdivide. So for me, this is a major bonus. For you as professional design firms, you may be well beyond the point where you're trying to teach someone how to use a grid layout. But that's where I start, is the layout and markup. The next step is decoration. So now we've got the fundamentals in place. We've got essentially our wireframe. They're comfortable with that level of configuration or styling or building or development, whatever verb you want to use for it. Now we start looking at the nuances of CSS and adding visual elegance to our sites. At this point, I tend to flip over to the adopter themes. I learned to theme for the most part on Zen. The documentation was outstanding even many years ago when I first started, and it has only improved since then. What I like about this is it starts to force people into learning more of the Drupalisms and more of the code that I would like to see out of someone who's progressed beyond novice. Maybe they're an advanced novice at this point. The next step that I take him through is into what I'll refer to affectionately as volatile systems. And this isn't to mean that volatility is bad. It's simply acknowledging what happens on the Internet. We could not have predicted responsive web design five years ago. And yet it's three simple little things. It's a media query. It's a grid that's aware of its context and it's squishy pictures. That was it. That was the original article. So simple and yet has revolutionized the way we build websites. We don't know what the next responsive is going to be. We know about mobile. We know about this stuff. But we don't know what the next sort of major disruption is going to be. And that's why I refer to these as the volatile systems. What I learned today may or may not be what I'm going to use tomorrow. And now we start getting into annexors because at this point we're bringing in a lot of technologies you're having to learn a very complicated system if you're doing the theming work. If you're doing the sort of pointy clicky stuff as the client in phase two of the website, you don't need to learn the underlying systems that make it work. But it's risky as a themeer to choose one of these systems because we don't know what's going to happen on the web tomorrow. And that doesn't make them bad. But it does put huge pressures on those theme developers to keep those themes modern, current, whatever the right nickname is for it. And ultimately the holy grail of theming is that you choose whatever system is most appropriate for you. And this in some cases means writing your own base theme. Because you pull in the parts that make sense for you, you adapt the markup where it makes sense for you. And in some cases you may also be bringing in extra modules if you're a panel or a display suite or a context kind of person. But you're starting to make those decisions for yourself once you've gone through those steps. So that's the progression that I use when I'm teaching theming. I don't think that there's a fixed way or a right way to evaluate base themes. As I keep saying, it depends on your context. Over on the right hand side, I've got things that I never, never is a really hard one for me to use, but never would consider when evaluating a base theme. In part because I would trust that the decisions that are made at the theming layer are, well, let's be honest, how many people have seen an SQL query statement in a base theme or in any kind of theme, rather not a base theme. And there's more than a few of you, right? So we're setting cookies that are then hard coded into, like I mean, like there's, yeah, there's some ridiculous stuff that happens in themes, but I would never expect that of a base theme. And so I tend to ignore the right most column, especially if it's been published on Drupal.org. And I trust the community to have done that evaluation for me. So the left hand side of the column, these are things that may be of interest to you, the number of installs, the lines of comments versus the lines of code, buzzword compliance, encode documentation, ease of installation, whether or not there's labels on the UI text. Sometimes there's not. There's just magical buttons that you have to click on things. Online documentation, so not just within the theme itself, but what's the documentation like on Drupal.org. And finally the support, both community free support and also professional support. And I really respected what Fusion and Topnotch themes did with their base theme because they were accountable to paying customers. I trusted that their base theme would work because they had paying clients who would complain to them if things were broken. So these are some of the things that I've considered. The previous issue of Drupal Watchdog had an article by Michael J. Ross, which is not online yet, but hopefully will be soon. And he had a great comparison chart. Do the equivalent for yourself. Put the stuff across the top that's, or down the side that's important to you. If HTML5 is really important, if responsive is important, everyone should care about accessibility, but it may or may not be something that you're being paid to care about. Again, if you're not being paid to care about, make sure your base theme takes care of it for you. Create that comparison chart for yourself and start to think about what's relevant for my clients today and are there different kinds of clients for whom different base themes are more appropriate. Again, base themes have nothing left to take away. And when I tried to get the original source on this one, you may have been awake or not. It was an IRC, though. We can go back and look at the logs. So whether it's Antoine Saint-Tucs de Piree or John Albin Wilkins or Leonardo da Vinci, they're all in the same camp, aren't they? So ultimately, we're looking at, with nothing left to take away, what do we build on? Where can we start from here? Morton had a great idea. Morton's the developer for the base theme mothership, and he had a really great idea when I emailed him a draft version of my slides. He suggested that I contact the base theme developers and ask them to evaluate their own base themes. So this is the email that I sent out. I'll show you which base themes I sent it to in a moment. But ultimately, we'll read this email together. Hello. I'm giving a talk on base themes. As part of the presentation, I'd like to highlight a few base themes. I'd like to include an honest evaluation of what developers of the base theme think of their own themes, strengths, and weaknesses. I'd love it if you'd take part. Please email me back with the answers to the following questions. Each answer should be not more than 140 characters, and I will trim at 140 characters. So this is who I emailed, and they're sort of grouped a little bit according to whether they are an adopter, adapter, or an annexer. Not everyone got impact back in touch, and that's totally fine, but you can see that there are themes in here like OM, which I didn't reach out to. So from this list, here we go. Four categories, your theme in a nutshell, its best feature, the worst thing about your base theme, and a notable difference from other themes. So the first one, and these are not in any particular order, but you can see up in the top left which of the three categories I think this theme fits into. So Zen was the first one, and Zen is a sass slash compass-powered smack-loven, drush-buildable, HTML5, Drupal-sterger theme with a responsive mobile first-grip design. I'm not going to read all of these words each time, but the slides are uploaded, so you can get all of this text. There's also a handout, which is about 11 pages, and isn't just pictures, it's actually essentially my script from this talk. So what we can see from Zen, though, is that the designer of the theme, the developer of the theme, is giving us for the most part some technical details about the theme. So I would expect this theme to be a technical theme. This is not a, hey, jump in, and everyone can learn how to theme, it's going to be the awesome. There's some words in here that you need to know before you can start working with Zen. Or as you work with Zen, there are some words you will need to learn. The next one is mothership. Lord love, Morton. So this one's short, I'll read it to you. Cleans up the markup and gives me what I want. That was two points. I could have put it into a second line, but I thought it was charming the way it was. Worst theme looks like Stark, and you have to know what you're doing. Smiley face. And the fourth point, which in our case is the third point, this is the most notable feature of the base theme. The most notable feature of the base theme, you get to swear like a pirate and wear little white sailor hats. And I'm amazed that I was able to say that without completely cracking up. Thank you, Morton. I'm sure that I'll be punished later for putting this on a slide. All right, so the next one, I'm not sure how this theme is actually pronounced. I believe it's Detomo like Alamo, but I'm not entirely sure. This one is an interesting one in that it's, I couldn't decide where to put it. And then I set up, but if I'm going to use my rule of annexors, you need to install a module. It easily fit into the adopt, although definitely with a lot of adapt stuff as well. So this is working with the 960 grid, but making it fluid instead of fixed. And it has a fixed with 640 pixel tablet and 320 pixel mobile layout as part of it. So it's taken 960 and adapted it to also be responsive. I think the big one for this one, and especially for, I tend to find that the European crowds care more about semantic markup and the American crowds tend to care more about how many classes they can use because it's easier to work. It's easier to work with those classes. So this one for me, the worst part is definitely relevant. It won't appeal to those who don't like non-semantic grid classes, and you'll have them for the desktop, tablet, and mobile grids. So for me, this is a huge warning that there's a lot of stuff to rip out if you want your base or your starting point to be semantically valid. That's the biggest one for that one. 960, this one definitely a true adopt base theme. It's bringing in the 960 grid framework. There's a little bit of math in the template.php, which allows you to automatically have regions stretch and squish. But essentially it is 960, as the name says. For me, the interesting one on this one, for almost all of them, the interesting thing was the developer's opinion of what the weakness was. So in this case, with the rise of SaaS and Compass, and responsive design, the 960 grid system is no longer the best starting point for grid-based design. I still love it as a teaching tool, but it may not be something that you want to use to deploy your client websites. Maybe it's perfect if it's on an internet that will only show up on a desktop, and your team that you're working with has limited web tech skills. So there's going to be times when it's still great, but for the most part, we may have moved on as a web development community. Square grid, this one gets props for having one answer that's exactly 140 characters. So this one, again, fairly technical. One of the things that I do like about this in the positives is the child theme could be done in two to 400 lines of commented CSS. Now, square grid, you do have the 35 columns, which I think is a lot, if you don't know how to work with that. But ultimately, it is what it says it is, it's that grid framework. On the notable side, this is a theme, this is not a theme that tries to make your coffee. Settings are minimal, and power is in the square grid CSS. Blueprint. This is one of the classiest answers that I got. So the blueprint developer said, thanks for contacting me about blueprint. Unfortunately, at this point, I will have to back down from this opportunity to answer questions about blueprint. Since I took over the development, my interests have moved beyond what blueprint provides, and I am no longer able to maintain or develop it. At this time, I would like, however, to find another developer who can take the theme on and really make it shine. Blueprint is great, but as I have started to use responsive design technologies in my designs, I have moved beyond the limits and begun to use, how do we pronounce that word? I love how everyone just hissed back at me, that was awesome. But this is a classy response in the sense of it took a while for this email to come through, and I'm guessing that this person had to decide whether they really wanted to admit that they're essentially abandoning the project. And I think that as the web changes and it's going to continue to change very quickly, we need to evaluate the projects that we put up on Drupal.org, and we need to be saying sometimes this isn't the right answer anymore. 960 did the same thing. I mean, I love 960, so I'm really glad that Todd actually completed the email for me, but it's something that we need to consider. When do we outgrow our stuff, and then how do we politely let people know that there's other things out there that they may want to look into? Adaptive theme, another answer that is exactly 140 characters, kind of got a kick out of these. Yes, I actually went through and counted everything. So the notable ones for this one uses responsive plugins to support panels, panelizer, and display suite. The rest of it is interesting, but for me, for Drupal 8, this is the one to start with on 7, considering the changes that are coming in 8 with the layout tools. So if you want to get practiced now on using this kind of functionality in your base themes, and you want the extra overhead of using an Anexer base theme, I think this one is an interesting starting place. Under the limitations, I do quite enjoy the undocumented Easter eggs, but again, they've all got the same kind of flavor in terms of buzzword compliance and technicalness. Finally, we've got Omega, and how many people are using Omega right now? So this is a different kind of answer that we've got for this base theme than the other ones. Most of the other ones focused a lot on their technologies and buzzword compliance stuff. This one, it's weak point is that it fails to make my coffee or clean my house. I don't want that out of the base theme. I don't consider that a weak point. So whereas that was a sort of a positive thing for some of the other base themes that were focused on the grid frameworks, this one is a, I expect it to do everything, and it's going to be the awesome. And it's just, it's a different flavor of answer to some of the other base themes that we saw. It also, I'm sorry to say, is the only one that failed to actually limit themselves to 140 characters. So this was the, in the final answer on the notable features. And it does have a very passionate community with it. I think part of that is to do with the learning curve of Omega. There's so much in there that you need to learn. Once you've accomplished it, like with Drupal, you want to be able to share that knowledge with other people, and you want to be part of the experience of this thing that you've invested so much time into. So I think we're seeing part of that reflected in this answer. So again, we've got these, these three essentially categories of base themes. We have our adapters, our adopters, and our annexors. And within the adapt, there's Zen, Boron, which I didn't even mention in that list, mothership. And they're going to rewrite some of Drupal's core markup. And in a lot of cases as well, some of the contrib markup, so that you get a sane starting point. And this could be for workflow reasons, semantic purity. Maybe you're wanting to use JavaScript or jQuery libraries with your work. And you need to get exactly what you expect each and every times that you can drop in these other libraries. Those are your adapters. Your adopters are for the most part bringing in some kind of external best practices. These were the ones that for the most part were also referring to being deprecated. It's no longer the right way to do it. So the adopters, they're perfect at the time. You can leverage that technology that's been established outside of the Drupal world, but don't expect it to stay forever. It's still valid. It just maybe isn't as up to date. And then finally, we've got the annexors. The fusions, the omegas, the adaptive themes. I'm sure there's more of them out there as well. These are the ones that I sort of affectionately refer to as my volatile systems. Because they've got a huge learning curve to them. They make a lot of changes. They make a lot of decisions for you. They're fantastic for clients who want to be able to maintain the layout of their site in sort of the phase two of your theme. But they're also kind of risky. If you adopt an annexor, and it isn't able to keep pace with the way the rest of the web is going, you've got a lot of parts in there. You've got a lot of components that you're going to have to rip apart or tease apart to move forward with the next generation, as opposed to just swapping out a grid framework. So, I did promise a winner. However, let me lie. No one gets to win at base themes. And again, this is just going back to, yes, seriously, going back to what I was saying about it's what makes sense for you and your team. And I'm hoping that by showing you, by breaking down those base themes into different categories, you can start to make perhaps a more informed decision, or you can start to think about those base themes a little bit differently. It's not just who's got HTML5 or who's got responsive or who's got SCSS starter points for you. It's what makes sense for me, where I am today with the skills that I have, what makes sense for my team, what's the easiest to collaborate with. And you may have to, you may be using something that's just a grid framework to bash out a prototype. And then you've got, you strip out the base theme and you start with custom work for your clients. There's lots of different ways to use these tools. And I don't think there should be a single winner. But it's, I guess it's more than that for me. Because for me, it really, it shows how the question is completely wrong. If we're saying which base theme is the winner, which base theme is the number one, we are fundamentally not respecting the problem space that we're in right now. And so that's the first bit of the presentation. And now, now I want to stop in and basically reframe this question. And I ran for political office last year. I'm here today because I didn't win. Well, I'm here today for other reasons as well. But one of the things that we got in political training was a lot of exposure to George Lakoff. And one of the biggest takeaway messages for me is that as, as a politician who's receiving questions, I need to decide if I'm going to accept the frame or the language of the question. So perhaps the, the biggest or most famous quote that we all sort of throw around is once the issue is framed, if you accept the framing, if you accept the language, it's all over. You're now playing someone else's game. So stop before you answer that question, stop and think, how is it that, what is the language I want to use? How is it that I want to present the answers to this problem? And for me, it's not to do with base themes. So this is a restaurant that's local to me and there's a bunch of dead animals on the wall. Now some of the dead animals have hats and funny noses, but ultimately there's still dead animals on a wall. Part of my concern is that with the changes that we're looking at in Drupal 8, like punting, I shouldn't put, I shouldn't put negativeness on it. By putting twig into core and either giving alternatives or completely replacing PHP template, I'm worried that it's like putting a hat on a moose. I'm worried that if we don't go deeper into the problem, if we don't also look at the theming system, but just the templating engine, we're going to end up with something that doesn't actually meet our needs as a front end development space. And so this is where, this is the part that for me I got kind of a little bit nervous about, but everyone in the audience is like, yeah, we know this. So I don't need to be nervous. So the rant goes, something to the effect of this. Front end development is frigging hard. And we need to start actually giving respect to the front end developers who are doing this work. Sequel query statements basically haven't changed in the decade that I've been doing them. HTML has changed. We're on version five. And I understand that my SQL is different. And yes, we've got Postgres and we've got no SQL and la, la, la, but an SQL statement is still an SQL statement. So what I would like to see is that we start as themers and designers saying, this is the framework that we actually need to do our job. Get your frigging CSS grid frameworks out of core. We want it to be adaptable. We want it to be responsive. We want it to be, but not responsive in the sense of today's responsive. We wanted to be able to respond to what the web is doing. We need to actually put the energy in, though, as the theening community to decide what that looks like. And it's not good enough for us as a theening community to allow developers to make those decisions for us. We can't simply say it's good enough to have a hat on a moose. We need to actually make those decisions. Last year at Drupalcon London, Eaton was already, and I wouldn't count Eaton as a professional femur, but he was already making jokes about how horrible our theening system is. I don't know if any of you saw this slide, but the bottom right, that's a theming issue. Shouldn't get laughs anymore. It should get outrage and frustration. We know that it's a problem. He told us about it last year and he's not even a femur. So what are we going to do about it? Well, ultimately, people are already doing things about it, but fixing themes is going to take more than a single step. You can see that there's a series of platforms on this staircase. And each time we get to a new platform, we need to look back and remember where we've been. And we also need to look forward and think about the changes that we want to have. How is the web changing categorized? Like I did those three, you know what, we've got adopters, we've got adopters, we've got annexors. What are the kinds of things that as a femur, you need to be able to do? Do we get rid of this folder called themes? Do we have palettes and layouts and framework, grid frameworks? Like what does this look like when we start to imagine a front end framework? Not just a developer framework for module developers, but what if we learned how to do module development? What if we weren't trying to decide whether something belonged in a theme folder or in a module folder? What if we all had John Alvin's amazing capacity for tiny little modules that do exactly what we need? The work is already being started. So just in a second here, don't make me click you again. All right. So work has started. If you are currently working on Drupal 8 core theming stuff, stand up please. I know there's some of you. I know there's some. For those of you who are not in the room, there was two people standing up. This is important stuff and this is stuff that you can contribute in. You have on the ground experience. You know what it is that you're bumping into. You know what isn't working. You may not be able to imagine the toolkit that would make it easier, but you know what the problems are. So what I'm going to get now is everyone to stand up and take the theming pledge. And this is not a suck less. We are not going to put a hat on a moose. What we are going to do is we are going to say all together now, I promise to help make theming rock in Drupal 8. Thank you, everyone. If you are indeed interested, you can sit down now. I promise it wasn't meant to be a standing ovation. So if you want to be part of the solution, there are two sessions that I think will be of utmost interest to you. There's a designer friendly theme system in D8 session, which is this afternoon. And then there's also a new theme layer in Drupal 8, which is tomorrow. So those are the two sessions that I would say, even though they're core conversations, you don't have to be a core developer to show up and have an opinion on things. Yes, we need you at the sessions. So do you want to come on and I like speak into my top because this is how it gets really awkward really quickly. The first one is going to be introduction to the entire system. And so if you don't know anything about it, that's a great place to come in. And the second one is going to be a conversation of how you can help out and contribute to it. Those don't need to end up on the internet, so you can just put your cameras away again. Thanks, John. So get involved. Have your own little rant, but also do some thinking around what could this look like if it looked better? And for you, that may be taking the components that you currently work with and subdividing them, like I did for those three different kinds of base systems. So what is it that you do on a regular basis and what kind of front-end developer framework would help make your job easier? Thanks, everyone. Don't catch sharing. We have four or five minutes left. There may be questions. I don't see a mic on the floor. I'm just as happy, though, people head out to the next session or lunch or whatever it is. If you happen to have them, that's great, but I don't expect any. So thanks. Stick around if you've got them. Wave your hand if you do. Yes? Yeah. So the question, I'm just going to repeat it for the recording. Do I have suggestions of other theming systems that I think work well for designers? And to be perfectly honest, I haven't been looking. Jen has spent a lot of time, Jen Lampton has spent a lot of time looking at other systems. I've been mostly focused on getting Drupal people trained, and I'm seeing a lot of pain, but I haven't been looking to see who's doing it better than us. And I'm sure that other people will have answers. So stand up and wave your hands wildly. So, and everyone, if you have the answer to that question, that's who's, I'm sure everyone wants to know, but anyone else with questions? All right, go away. Bye.