 I'm Kevin O'Leary. I'm a user experience designer from Acquia. I've been in brand design and graphic design and all kinds of different design for the last 20, 25 years or so. And today I'll be presenting with Martin Verberschot. Martin, you want to talk a little bit about yourself? Hi, I'm Martin Verberschot with Projects. I spend my time mostly making themes. I communicate a lot with external designers and try to be the person who coordinates stuff between designers and themers to get the optimal results. So what we're going to talk about today is a kind of a combination of brand and theming. I'm going to get into a little bit of sort of theoretical stuff about brand and a little practical stuff about brand. And then I'm going to kick it over to Martin at about the halfway point. And he's going to sort of get into more of the nitty-gritty, you know, actual theming nuts and bolts of the things that you can do to make this a reality in your actual sites. So as I said before, I've been involved with brand for a very long time. And long before actually I was involved with theming for Drupal or even with user experience design. And, you know, one of the things I wanted to do when I put together the presentation is I wanted to, oh, I'm sorry, actually, first of all, before we go any further, I wanted to ask a little bit about who's in the audience today? How many of you would sort of self-identify as a module developer? Designers? So there's a lot of designers. Project managers? A few of those? Themers? Okay, about even on themers and designers. So anyway, so talking about brand, I wanted to, I was putting together the deck for today. I wanted to try to find some kind of a funny or humorous or insightful, interesting quote about brand, maybe from one of my sort of design gods like, you know, Massimo Vignelli or Paul Rand or one of these people who I looked up to in respect. And I was doing a lot of Google searches around, you know, brand and quote and funny quote and funny brand quote. And unfortunately, I wasn't really able to find anything really funny. And the thing that kept popping up on funny and brand and quote was Russell Brand and funny quotes from him. And he's a very funny man I thought kind of dovetailed in quite nicely since he's English. So here's a little quote from Russell Brand. It's, even as a junkie, I stayed true to vegetarianism. I shall have heroin, but I shan't have a hamburger. What a sexy little paradox. So I thought that was quite funny. Anyway, it does say a little bit about personal brands and people talk a lot today about personal brands. People have a personal brand. Do you have a personal brand? And, you know, obviously sexiness and being a kind of a rock and roll poet and being a former junkie are all sort of aspects of Russell Brand's sort of quote personal brand. But I think this is kind of, it's a little bit silly in a way because the brand really is something that's sort of an imitation of something that's really an essential human quality, which is the personality. So these are really kind of aspects of his personality more than his personal brand. And, you know, I think that all brand kind of grows out of the personality. Everyone has, you know, facial features, a dress style, a tone of voice, you know, expressions, things that they do, all of these aspects that sort of add up to who we are. They're sort of natural and they're the natural way that we sort of interact with each other and know, you know, who's who and whether you can trust somebody or whether you really want to be friends with somebody, how you interact in social situations. It's all about, you know, essentially about your personality and the brand is really, it's an impulse that arises out of this personality. So what I'm going to do right now is I'm going to talk a little bit about sort of, I'm going to do the history of brand in three images. So the first image here is this is an ancient Indonesian mask. And one of the first ways I think that human beings ever sort of began to identify themselves as a group is, you know, through creating forms of dress and masks is one of them scarification. Lots of different ways that people, you know, did things to themselves to say something more than this is just who I am, but I identify as part of this larger group. So I think it was really interesting that sort of this shape then kind of gets repeated through history. This sort of face shape gets translated into other forms. We fast forward into the Middle Ages and you've got this sort of shield shape that echoes that sort of mask, you know, form. And then this is, again, this is kind of an example of a group, a group identification. You've got the coat of arms, which starts with the family and then it becomes something that identifies, you know, the city state, the nation state, you know, and larger and larger and larger and groups of people over the course of history, you know, create these symbols or images to essentially put an image or a personality on a group. That's essentially what the brand is. It's putting a personality on a group. So fast forward to today and we have, again, the same shield, the same coat of arms is still reappearing throughout, you know, modern corporate branding and it's echoing and it's drawing from this essential quality of, you know, let me try to put some kind of visual structure on a group to create a personality for a group, which is what a brand is all about. It's the shared identity of a group. So what about the theme? So the theme, obviously we're here to talk about Drupal, we're here to talk about Drupal theming. The theme essentially is the same thing as the brand. It's just the expression of the brand on the web or in electronic form, whether it's on the web or on a mobile phone or however you're using Drupal to, you know, to disseminate your theme, you know, across the world. The theme is really inextricable from the brand and it doesn't matter whether your organization is a corporation or a non-profit or a government agency, these are all, the brand is sort of, you know, essentially just that expression of the identity of the group. And so what you want your brand to be is you want it to be consistent, you want that expression to be the same everywhere anybody sees it so that they can react to it and apprehend it and interact with it in much the same way that they would interact with, you know, on a human level with another person. You want your brand to be that personal expression of the group and that people can understand it and they can, you know, know about who you are and, you know, and you can put forward certain ideas like, you know, we're trustworthy or we're intelligent or we're, you know, whatever it is that are the sort of core values of the organization. So when you start in this process, I think it's important, I'm going to talk a little bit in a second about audiences, about personas and about, you know, how you know who you're talking to and who you're telling your brand's story to. But before you get into that aspect of it, you really need to think about who is this group. I mean, the brand is the identity of the group, who are the people in the group, and more importantly, who are the people in the group who are actually going to have control over aspects of the brand and over aspects of the theme and how those things are sort of, you know, passed out into the world. So I think it's important. This is obviously, this is not a, this is not every organization, but it's, you know, I think many organizations have, you know, similar categories to this, you know, when you're talking about, you know, creating a, you know, a site or a set of sites, you know, to carry forward your brand message, you usually have a product manager, usually have themers and developers who are putting together the site and then a lot more sort of what I call section owners, people who are, you have one person who's sort of the editor of the blog section or the editor of another particular, you know, section of content in your site or in your number of sites and then you have content editors who are actually involved in the day-to-day business of writing blogs, putting together articles, you know, getting, you know, the content which expresses the, you know, the ideas that are core to your brand out to the public. So it's important to think about them and then also Martin is going to get into, you know, at a later point, he's going to talk a little bit more about, you know, how we divide up roles and tasks and intelligently look at, you know, what each of these people does and how they, and what they have authority over essentially. So, but really ultimately what you want is, you want to have as little theming ability as possible at the lowest level and then, and by that I don't mean, you know, personal ability, the ability of the person to come up with theming, but you want to sort of take that out of the hands of the content editor or the section owner and leave as much as possible, you know, at the top of the pyramid so that you can maintain that consistency because otherwise you're going to have certain section owners theming things one way and other people are theming, you know, parts of their site in a different way and quickly everything starts to get out of control. And again, Martin is going to get into this sort of nuts and bolts of exactly how you do that, how you maintain that consistency and how you keep your theme small so that you can make sure that those things are sort of taken off the plate of the people who really need to be concerned about, you know, well, what's this blog post say, not what color is the H1 or what font is my text set in. So I'm going to talk a little bit now about audiences and personas. So how many people have worked with personas before or use personas in their day to day work? Okay, a few. So personas essentially, there's a lot of documentation. There's a lot of, you know, there's been a lot of writing out there about what is a persona. And just briefly, essentially a persona is the core user of the product or the message that you're trying to get across. So say, for instance, if you're talking about a product, the personas is the person or persons, and usually there are several personas in a personas document when you start to put together personas to figure out, you know, how your product or your site gets used. You think about two or three different sort of core users who are the people who are regularly using your product or regularly using your site. And that's very important. I think every design team and every project really needs to have good personas documentation and, you know, really keep going back to them on a regular basis to understand why are we doing these things? Why are we building in this way? Does it fit, you know, our personas? But then, in addition to the personas, you have this sort of greater universe of, you know, of people who might be coming to your site. So for instance, in the case of, you know, a company site, you might have your key personas, two or three key personas who are your product users. But then there's this other sort of, these other sort of ancillary kind of audiences, which are people who might only rarely or occasionally come to your site, but they have to be thought about and considered, you know, particularly when you're putting together your content strategy, your information architecture, and as well as your brand design, because brand will sort of, you know, will tailor itself specifically to certain audiences in slightly different ways. So in a company site, you might have partners, you might have media companies who are writing things about you, are writing, you know, articles about your company, you might have potential hires. You might have, in the case of an open source company, you might have, you know, community members, people who are, you know, are affiliated or associated with what you're doing, but not necessarily working or employed by you. You might have competition or investors, people want to give money to your company to make it keep going, hopefully. And, you know, all of these, all of these audiences need to be sort of taken into account in the, when you're thinking about how you, how you structure your, your, your site and your information architecture. So just getting into the IA a little bit, it's important when you, when you've worked with your content strategist and you've come up with your audiences and your personas to have a real, simple, clear visualization of your IA. And, you know, a lot of people use a tree, I use a tree, it's not essential. If you have some other visual metaphor, which you, which you find more appropriate or what you think is a better way to, you know, to step back from the, from the hole and see sort of all the parts and how they work together, then, then that's great. But it, it's just important that you can do that, that you can sort of get it all out on paper, print it out, maybe put it up on a wall. A lot of people put it up on a wall. I know that when we were working on the Aquia site, we took the, the entire old Aquia site, which many of you probably have seen from, you know, two or three years ago, or, you know, it's been around for, for, for a while before we, we, we, we did our update. And we, we took every single page in the site or every single main section page and printed them all out and stuck them all on the wall. It was like an, it was a wall the size of the screen, filled with pages with little pieces of tape and, you know, sharpie lines going in between them. And as soon as you see all that, you know, it was a great eye-opener for us because immediately we, we saw all these holes and, oh my God, look at this workflow here. What is the user going to do here? They're, they, they're sort of set down a, you know, shunted down a dead end and, you know, oh, here's a hole and, you know, things, you know, come forward very, very quickly. And then we used that to create, you know, an information architecture map that for the new site that sort of was more, you know, more well-organized. We were able to step back and see the whole picture and sort of map it out. Where do we want, what do we want to happen in all of these different cases and for all of these different audiences and sections within the site? So then the other thing that you can do, which I strongly recommend, is to create a master theme document, which is in, in, in the case of what we did, we put together a document that, that was, that was done in the context of, of our site design, of our approved site design and, and showed how every element of the site was going to be themed. Now, chapter three put together a great one of these, which you can, which is available on the web. Interesting side note, you'll notice that chapter three has a new logo too. So people are constantly rebranding and updating. And this, this is for a few, from a few years ago. And you'll see that, that their whole brand identity has evolved and, and, and changed. And I love the new stuff that they, that they're doing now. It's really, it's really terrific. But they put together this document a few years ago, which is essentially, it's a, it's a multi, a multi state fireworks document that has essentially every single element that you would need to theme in Drupal. And so a designer can go in and open this document up and sort of essentially just, you know, change fonts, change colors, change the styles and then begin to sort of build out their own branded sort of style guide from that. And that's essentially what we did. When we, when we created the Aquia site, we, we put together all of the different elements, all the different HTML elements, obviously age one through six, unordered lists, ordered lists, et cetera. This document actually, this is just, just a snippet of it. It went on for several pages and went into, you know, a great deal of detail with blocked quotes and, you know, two columns of text and, you know, little pieces of intro text, all kinds of different theme elements as well as, you know, overrides, things that would, areas where the, where the essential theme would have to be overridden. For instance, in the sidebar, you know, there's, there's a different ordered list style than there is in the, in the main content area. So that's just sort of, you know, kind of a quick overview of, you know, of starting with brand, thinking about brand as the face of the organization of, as the, as the sort of personality of the group and then how to begin to, you know, pull that all together and, and put that message into, into a theme which is sort of synchronous with the brand and, and gets across, you know, your brand personality to, to the, to the people who, who you want to, to see it. Now, Martin is going to get into talking about, you know, some of the nitty-gritty theming elements and, so, and then, you know, we'll, we'll go into questions after that. So, go ahead, Martin. So, whose theming folder looks like this? I don't know, I've had selectors that look like this. And we've all had these moments that clients have added a page or a block and they had to call like, hey, it looks not themed, can you do that for me? This happens to a lot of themers and, well, we're going to take a look at how we can make things more robust. So, and it's actually a thing that not only themers have an impact on, it's why we ask, ask, like, are there project managers and module developers in the house? And, so, in this session, I'll mostly take a look at things from a themers perspective, but I'll also mention just a few things for developers and project managers to just pay attention to. So, the problem actually is that there's no amount of abstraction between the content of the site and the presentation of the content. So, every time there becomes, every time the content grows or changes, then the theme needs to grow. So, what we want to do is like make the theme behave like a lens. So, the site can grow, but the theme will stay the same size. Sure, it might grow just a little bit from time to time, but there will be abstraction between the two. So, I came up with just a set of principles that I stick with to make themes more scalable. This is about separating structure from components, and a component is code that just works regardless of context. So, it can be a block or a menu or maybe a search field or just anything, really. And the whole point is that it always just works, no matter the region or the page. It's always the same. And structure connects these components with content so that we form a page. The structure of the page can be easily seen in Drupal, just going to the block administration page. There's no content, no components, so we just see the structure. Then once it's connected, it can look like something like this. In this process of working with components, markup is central. So, every time, every time you need to add something, you look at the pattern library, like Kevin showed you from the Acquia side with all the what does a heading need to look like or how does a search block need to look. You look at that and you match it with a component. If it's not already built in, you build a component. Then, you know, which markup to write for that piece of the design. And the important part is here that it needs to be documented. So, when you look at templates in Drupal, you'll always see these massive comment blocks. Documentation for components doesn't need to be that big, but it's about module developers that maybe may not be familiar with front-end development best practices. And those are really the people that you want to document for. Like, I've created this component and every module can use it. It's maybe a piece of CSS or JavaScript. So, just document how it should be used. It's also important to stick with it. A lot of people are a bit unsure about it. When you work with external designers that may not understand all of this. I don't know how Drupal works, but that's not the point. You should take control of that. And, for example, in the design I showed earlier, we had two different search blocks. They're both search blocks, but one has a blue button. The other one has a black button. So, you could style those based on the region that they're in. But then you're back at the beginning and you've thrown everything overboard again. So, it's important to start learning to think in defaults and overrides. Everything needs a default. So, when people add stuff, it will always look acceptable. So, usually the most simple version of something is the best default. And, the way we do this is we use Cascade in CSS to make overrides of components as efficient as possible. So, back to that. The one with the blue button will be the default. And, the override would just override the color of the button. So, we stack the classes and that way we can keep the benefit of it being, you can predict what it will do. It will always be that search block with the black button. And, when we talk about sticking with this way of working, people tend to make separate stylesheets for fixes, for example. And, this is also something that doesn't really conflicts with it. Because, once you change a component, you should be able to predict what effect it will have. And, if you have fixes for that component in a separate style sheet, you can quickly lose sight of that. So, one thing that HTML5 boilerplate, for example, does is add classes to HTML elements. You can put them on the body or inside the body. It doesn't really matter. But, the point of the class is that you can style things for separate browsers in its own context. So, keep everything in sight. So, making components is basically just writing CSS, JavaScript, maybe, you made a template for it. But, how do we connect it with the output from modules? Modules have a lot of classes by default, but they don't match the classes that you came up with for your components. So, there are actually modules that can do that. This place we, I think most of you will be familiar with. You can use it to connect classes or markup with entities. So, notes, user profiles, comments. And, I've had situations when a designer just gave me three designs. I had like 20 content types and had to match them with the content types. And, when I didn't have this place we, I just had a lot of templates with the same code just to match them with content types. And, with this place we, you can keep that to just one template and make the connection in the admin. So, block classes, well module which lets you add classes to blocks. So, it sounds a bit weird maybe to add a class for blocking the admin instead of in your theme. Which actually makes sense because blocks by default have classes based on the module that it comes from. And, well, as a themeer you don't really control which modules are used most of the time. So, you want to be able to make a module developer set the class himself once he came up with a block. And, that way your sign will automatically be attached to the block that he came up with. I believe the module also lets you create templates for the block that you just create a class for but actually never use that because most of the time you just change the stuff inside the content variable of the block. The block markup is by default just a wrapper. So, menu attributes lets you do the menu items. Add classes to menu items and I see lots of people styling the menu items based on the IDs that menu items get which is possible but it can get really risky when you work with multiple environments like a development environment and a production environment. The IDs will change maybe, you know, up front. So, you better be on the safe side and just use classes and attach them again at the admin. Fuse has a little field at the left bottom of the interface I believe to just add a class to that field. And, it's basically the same thing with blocks. You don't know what the view is called or maybe there are multiple views that need to have the same styling but they all have different classes because the name of the view is different. So, you can use a field to add a class view component. Sematic Fuse or Fuse 3 also supports adding classes to rows and fields so you have just a little more control. So, control is nice but the problem is that you can't really reuse it every time that you need to change something you need to change it multiple times if you have used it for multiple views. So, display suite again is also able to add node displays for a few. So, you just have a template for a node layout and use it for certain views. That way it's in the repository so you can have again just one place where you can change things. Fuse style plugins is actually really scary for most themers because it's object-oriented PHP. I know that I can't really program object-oriented PHP but it's also just really powerful if display suite or semantic Fuse or whatever can't help you out, this might be your last option and in that case I would advise to work together and let some module developer help you out with this. So, it's important to invest in defaults. Everything has a default in Drupal. So, when I said learn to think in defaults, Drupal actually helps you with that. And the reason that this is important is to make the admin not rely on themers. People need to be able to do things in the admin without constantly having to consult themers like I've changed it and now it's broken. And we want to keep the code base small, just efficient and we want to do everything once like I said, when you need to change something you don't want to do it six times. So, a good default is flexible so you don't have to override but simple in case you do have to override and that's about just not having to do things versus being to do things easily really. You can have a really great default that works for as long as it works but if it's really complex then you can really override it all. The thing with defaults there's a lot of criticism on markup in the Drupal community of which a part of I agree with but there's also just a lot of bashing on the classes and extra divs and if you don't know why the classes and divs are there I can advise to read the Drupal markup guide which was actually written for module developers so you can also just take a look at that like how do I document components for module developers is just kind of the same thing but in more general way this tells you like how are classes structured in Drupal. It's really to love the, just learn to love the markup actually. Don't take everything for granted but just don't change it because you, it's not how you would do it. It's made with the point of just making it more flexible. Zen is a base theme that, well the mission is to have a place where you can quickly improve defaults from core or for contrib modules and have the benefit from that immediately once it's committed and not just that major Drupal releases. So if there's a markup that you really can't live with then well just change it but then I would say also consider turning it into a patch as well once you've done that anyway. So fix the defaults and just help module developers out of this and hopefully you won't have to tweak everything yourself constantly so you can just focus on your own project. We want to keep everything simple. So it's about when I said like overriding should be easy. The idea is not to override in the first place where a theme stays small. It's like one of the principles like key because it's small but there are actually times when overriding is a better case. So the compass or SAS hype it doesn't really have much scalability but there's one little thing that I wanted to share with you in case you haven't seen it. There are people who like using sprites a lot and well it's great to just get a little performance improvement but the problem really is that once for example the icons on the left just in a redesign get a little bigger then all the images will move and you have to update all of the background positions in your theme which can get really complex and time-consuming. In here it's just compressing things manually which should never be done actually. You wouldn't compress CSS manually to the strip all the white space when you save it and then you can't edit it anymore. So the same actually goes for images. Compass let you just keep your images well organized and then let SAS create a sprite for you. So in your own code go at this and it will compile that into separate classes that you could use in the markup to get that specific part of the sprite that spot. And if you don't want to use the classes and you can use the mixings from Compass to add them to your own selectors. Keeping templates simple is well important and it's important to know when to prepostats, when to use theme functions or when to override and I've seen a lot of people just stack everything in the template but maybe they don't know what people says or maybe they don't know which theme functions are there so they don't know when to use it. Prepostats are basically just to separate PHP logic from markup. So markup stays readable. That's about it. Theme functions are basically like components. They always do the same regardless of where you are using the module or theme. Once it's available it always does that one thing. So they're predictable. I've had a site with lots of lists on it and for accessibility reasons it became a requirement that every list had its own skip link. So if every module and every place in the theme used the Drupal's theme item list consistently that would only have to add that skip link once and then override the theme function and put the code in between. But a lot of modules don't actually so I have to change it to like 20 places. So this is a thing where I would like to just start making patches and get all modules to use theme items consistently. It's also important to know when to get someone else. So some people might be just a little afraid of this. I think their manager will get upset or something. But the principle is really about saving time staying focused and doing things properly. So the thing about view style plugins with OOPHP. Sure I could learn to program like that but it would be a great distraction for me as a front-end developer. So to stay focused I would say get someone else to do that. Get someone to help you out with that. So another example when it's good to collaborate with developers. A client wants something like this. So I have a content type with a lot of fields and they all have a lot of text and they want a table of contents at the top of the page which could jump to all the separate fields. So I could come up with a solution for this as a theme which would probably be something like I create a template for the content type and then add a pre-processor for it and loop through all the fields and create a variable table of contents and print that in a template. And then I would override the field templates and put the IDs in there so I can actually jump through those. But yeah it's more a functionality than how it should look. So it makes a theme bigger without being actually useful. So this is a case where you actually want just this. You want extra checkbox in the display settings and say like I've created a new field and this one should come up in the table of contents or not. So we have more control and you've made it more scalable. So maintenance gets considerably faster and you can reuse it more easily across projects if you want to. Collaborating with fellow themers who work on the same project is not always easy. You'll quickly get in each other's way. So this is what a lot of companies do I think just say do you want a themeer like you go theme the blog, you the web shop and you the forum section or something. So based on site section you assign tasks to people. But this really could cause conflicts because there could be a lot of components that appear on multiple sections of the site. So then you still don't know who should do what. People will get in each other's way. And the thing that a lot of people already do is separate elements starting from page structure. For example with a reset.css and a layout.css it's one way to do it. You could keep doing that with components so I don't mean just create separate style sheets for components. That's not necessary but assign components to people instead of site sections. So this prevents people from having to constantly touch each other's code. But yes you still need to document as documentation is more about maintenance than about initial development so you'll still probably be confronted with each other's code sooner or later. So I think a lot of what Martin has said and gone through kind of talks to the fact that you want to essentially keep it as simple as possible so that you divide up your tasks well between your theme you you create a simple clean lightweight theme and you don't create a situation where I'm sure we've all run into where there's something that's not themed and all of a sudden people like I've created a new piece of content and it pops up and it needs to be themed. Anything that anybody creates at any time in your site should at least appear with some kind of a default theming on it. That you've designed and that didn't come from a module and that didn't come from the defaults of Drupal. So that's the sort of holy grail that's the ultimate goal and I think that a lot of these the sort of steps that Martin outlined can lead to that. The real thing that sort of brings this full circle and makes it so important is remember when I talked about Chapter 3 and how they updated their brand well we did the same thing Acque updated our brand. Companies update their brands, they change their color palettes, they change their font choices they constantly evolve their brands. Brands are not static I don't know if anybody has ever seen this sort of evolution of the sort of Coca-Cola logo over the years you know things grow and change and evolve and that's definitely going to happen. So what you don't want to have happen is okay we changed our logo now I have to update our company logo in 500 different places. Wouldn't it be great to just be able to go in and update the company logo in one place and that single image file is being referenced everywhere. That's just a simple kind of a simple example of essentially what we're talking about if you theme intelligently and you use some of these methods then what you theme intelligently both from a design perspective and from a an actual theming perspective then you have to do things far fewer times you change a few simple things and they cascade through everything. That's why we have something called a CSS cascade so that the simplest changes can affect everything in your entire site no matter whether your site has 50 pages or 5 million pages it's all there in the cascade that's why we create classes that's why the sites are structured as they are that's why Drupal has a theming layer so that these things can be done quickly and simply and you can make big changes to your design without having to worry about going and cleaning up every little place that it might be different throughout the site. So designing repeatable patterns and designing for the CSS cascade now and if you didn't do it right the first time which I think kind of was the case with us then you really quickly learn this lesson because you go through and you're like now I have to clean up all of this I have to go through and I have to do this sort of back breaking work of going through everything and changing all these little overrides and hunting throughout the site for things like for instance inline CSS styling which is the bane of our existence so don't assume your old content seamlessly into the new theme certainly if you didn't follow the steps you're going to have big gaps and big holes and things are going to reflow and it's going to be ugly and I've been in that world and I don't want to be in that world again and so you redesign, you rebuild and you do it right the second time you follow a pattern and the flow is going to save you it's about saving you immense amounts of work down the road by doing it right the first time essentially and then the other thing is to go along with what Martin talked about in terms of documentation and the importance of of themers and developers not just writing a little comment in their code but writing real multiple paragraphs of detailed documentation and I did this because and if you use this here it will act in this way and this can be reused for these other purposes so real detailed thoughtful documentation throughout everything and that's true of designers as well we're all designers who, any designer who came out of the print world as I did years ago is very familiar with a brand standards manual well, you know I think the brand standards manual is essentially a thing of the past it's kind of an archaic way of looking at things you have this sort of static printed document that you disseminate around but a brand standard site is a much more sensible and really valuable document not just for not just for themers and not just for people who are maintaining or building onto or growing your site on an ongoing basis but for all the people who are still maintaining the traditional printed assets of your organization I mean if you're a doesn't matter whether you're a non-profit or a corporation you're gonna have printed materials collateral that you send out to people you're gonna have training materials you're gonna have all kinds of other assets that are assets that go along with your brand and having all of those things as well in a brand standard site where any partner or any branch office or other people who collaborate with you can just go and quickly grab the assets that they need and have permissions and roles to be able to get into that brand standard site and just and get that logo designers how many times have you sent an email from somebody can you send me the logo if you have a site where the logo exists that task is now off your plate they go they get the exact logo they need in the format they need you've got it there in multiple different formats and people can can have a resource where they can go to and constantly know the current state of the brand because the site can be updated on a weekly basis so if anything changes it's instantly available to everybody so and obviously your master theme having your master your master theme available then you can re-theme other you can use that you can use that theme as a theme for other sites which is something that that we've done you take a theme that you've created for one site and clone an entirely new site from that so with that we'll take some questions anybody well first of all thanks guys great talk the question that I had was in for theming actually I use less CSS or similar to compass and I try and use stuff from Nicole Sullivan and the sort of object oriented CSS notion is that something that you'll do in encompassing functionality for a block to actually enclose it in only one sort of ID selector or that kind of notion and then kind of have all your CSS encapsulated within it well certain styles should only apply within the block section well sort of nesting selectors inside sort of a global one for that entity you really need to be sure that you know components on that page that need to be used in a different section I do think it conflicts with the whole idea behind the component styling because the idea is to never you never know when you might need to reuse something so maybe you aren't reusing it right now but maybe it gets redesigned just a little bit so it can go on the web shop section as well or I don't think I'm getting it across well I'm sorry because I think it would support that actually if it's this is how you identify that component but it's just a way of writing the CSS so it actually isolates those selectors and they can't kind of bleed out of that that styling for that component I think the part of the components is that they can bleed out once you would want that or once someone who doesn't control the theme but is doing things or adding things in the admin that once he does that things won't look like crap and if you isolate that then there's no point really in thinking in components because once you've made them you're locking them so to speak you can't reuse them in other sections of the site Thanks Part of the biggest problem we've encountered so far is really for front-end FEMA coming in on a Drupal 5 project and converting to Drupal 7 for future expandability how would you document the theme for future expandability in so far as how would you itemize where all the components the classes belong within the CSS sheet if you've got a CSS sheet of 2000 lines how would you summarize that and explain that within the site or within your style guide for future front-end developer So the CSS is probably not well structured or what really is a structure itself if you want something to go easily go in there change an image to another image how would you easily explain that for another front-end developer coming in and taking the project on maybe two years down the line So I think I might be able to answer at least part of this because that's one of the things that we went through recently is upgrading from D5 and essentially a lot of times you really just need to throw out a lot of that old CSS and rewrite it Ideally, hopefully you don't have to throw away code that people have spent time on and worked hard on but sometimes you do but I think that if it's well commented right in the code itself that I don't know whether you can talk to that a little bit in terms of how your process is for documentation or best practices for documentation of CSS style sheets I kind of see a template.php with a lot of pre-processors and theme functions they always have the typical comment blocks above this function does that and then the longer description if necessary when I write components I just have the same structure just blocks or components and every block has just a comment above it just a small or big as it needs to particularly instructions for module developers like use it like that just as simple as possible but don't leave out too much details for example with when I need to document a component that is a skip link or something then it has like certain classes attached to it which lean on maybe some helper classes like in Drupal 7 you have element focusable which leans on element invisible so together they make invisible links focusable with the keyboard so things like that really need to be documented I really like what would I need when I were a module developer to use this really hard to explain when I don't know what code exactly is there did that answer your question? anything else? okay well no more questions I just want to thank everybody for attending and enjoy the rest of the DrupalCon