 Welcome, everyone. Hola. This session is Design Systems and Drupal. My name is Larry Garfield. You may know me online as Krell. If you want to make fun of me during this session on Twitter, that's where you do so. I highly encourage it. I'm a senior architect with Palantir.net. We're a web development firm based in Chicago, working mostly but not exclusively with Drupal. We also do some symphony work and Sylex work. For Drupal 8, I'm the Web Services Initiative Lead. Drupal is representative to the Framework Interoperability Group, advisory to the Drupal Association, and general purpose lovable pedant. My colleagues at Palantir will tell you the second half of that is very true. So, I'm a developer. I write codes. What am I here doing, a design talk? Well, Drupal and design do fit very well together if you're thinking in systems, not in pages. That's it. That's the entire talk. Not pages. You can all leave now. All right, let's try a little bit more detail. Why systems? What is a design system? Well, first of all, you want consistency. Consistency in your aesthetics. If you're building a site, you want your artwork, your art direction to be consistent across the whole site. And you want your user interface to be consistent. You want visual cues on one page to be the same as visual cues on another page. That allows users to learn your site once and not have to relearn what you're doing every page. It makes it much easier for them to use, much easier to find content on. They can identify patterns in your design and leverage that to understand your site. It provides better efficiency. Who has built sites that have some, you know, 5,000, 10,000 pages at some point? A couple of people. Did you do 5,000 or 10,000 different designs? I hope not. That would be very inefficient. That's a huge waste. Design systems let you build sites that will scale to any arbitrary number of pages and still look good. It also means a good design system will inform your design as the site grows. Because your site is going to live beyond you. At least you hope so. You're not building a site that the client is going to throw away a month after you finish it. You want it to live beyond you. It's going to evolve over time and you want it to be able to evolve naturally. You want to give it natural paths for the design to evolve without having to come back to you. You don't want to have to come back and write more CSS every time you want to add a page to the site. That's wasteful. What is a system? Interconnected parts forming a complex whole. Interconnected parts forming a complex whole. Individual pieces that we assemble into a larger vision. In design, generally this consists of elements, components, and templates. Those are those interconnected pieces that we're going to assemble. Elements are your basic HTML. Your headers, your block quotes, paragraphs, your forms. That's your lowest level atomic piece that you're going to design. From those, you'll build components. Components are your page header, your page footer. If you have a hero element, I'm not sure if that term is used in Latin America with the big image at the top of the page. It's often called a hero image. Your navigation. These are larger chunks that you're going to build up out of your elements. But those are still independent chunks, independent components that you can reuse. And you'll use those to build up templates for your home page, for your landing page, for an event page, a listing page. That full thing you see in a browser is built out of. It's not a painting. It's not a poster that you put together. It is composed out of these smaller pieces. A common name for this idea is atomic design, where you've got an atomic-sized piece here, I think, Adam. You assemble into larger chunks, larger combinations, building molecules out of them, and larger and larger, and you assemble your site and your design that way. That complex whole, well, in most cases, is a CMS-driven website. Who's built a CMS-driven website? Why do any of you not have your hands up? We are at a Drupal con. Drupal is a complex whole built out of individual components. Drupal actually fits this model of design extremely well. So let's have a look at an example of this. We're going to walk through an actual site. This is pri.org. This is one of the major public radio networks in the United States. Actually, across the United States and Europe, I believe. Public Radio International. This is a site that Palantir built about a year and a half ago, I believe. They wanted to have all of their content from all of their various affiliate programs aggregated up onto one big site. Mind you, this is a public radio website, so we're going to have a lot of audio content but also transcripts. Generally, you'll have an article that has a text version and an audio version that go together. So how do we build this site? How do we assemble this? Well, let's start at the beginning. You're doing design. You're going to start with the basics, your color palettes, your font treatment, the mood you want the site to have. But I'm not a designer, so I can't go into this in detail, other than you can figure this kind of stuff out with your client, with the design, with your product owner independent of Drupal. These things should exist on their own. What fonts are you going to use? How are you going to style your text? Note, here we're saying H1s will always look like this and H3 will always look like this. An unordered list will always have its bullet points aligned this way. Why that way, instead of further-intensive or further-outdented? Because that's what we decided to do for all of this site. That's not done per page. That is done for the entire site. You can build that in CSS very quickly, very easily. You can start to see the patterns emerging you're going to have across the whole site. Number two, get to know your content. We're building content management system. We're building content-driven site. Why are people coming to your site? They're coming for content. What is your content? I don't know. It depends on your site. That's a question you need to figure out before you start designing. If your first step in design is to jump into Photoshop before you figure out your content, you are doing it wrong. Know your content first. In this case, for PRI, they had really only one secondary one, but one primary content type called Story. Story has the story's title, the date it was published, a section that it's from, an author, the program, because they've got different radio programs that a story could be coming from. Body text, images, various other bits and pieces. This is conceptually the breakdown of their content. Most sites will have a couple of these. We'll work with. So now you know what your content structure is going to be in the abstract. Now let's put that into a design. Let's start combining those colored palettes and other elements and create components to represent that content. We're building from the bottom up here. So let's start with the header. We're going to show a story on a page. We don't know the whole site. We don't know where, we don't know the whole site, but somewhere there will be a page that shows an individual story and it's going to have a header. And we want that header to have the date. We've got our date here, the author, we've got our author here, the title, the program, in this case it's the world, their particular program, and the section, Arts, Culture and Media. So we know all of these pieces that are going to appear on the page we've accounted for them, we know where they're coming from, we know that users will be able to enter them. We know, okay, there's an advertising driven site so we're going to need an ad block of some kind. We're going to have lead image, so it's a large image of something relative or related to the story, and a caption credit that's done here and the actual caption text. This is part of our header. And we're also going to have some share links. Think this through. Are those user editable? Is that something the content editor is going to be editing? Probably not, but we still account for it in the design. It's part of the design level component. We put these pieces together and we start to get the page. We start to get our story page. And here's that header we just described all the pieces of. Here's the image, the caption. We're just assembling the various pieces we're defining. This is the entire story here. And if you go through, I'm not going to go through every piece, everything on this page, in this column here, we can map to a chunk of our content into a field in our content. And those are the pieces we just described. And keep doing it. Just make more of them. So let's have a look at the homepage. Because clients always want to see the homepage first and they send the design that first. They want the homepage first, whatever. Ask again, why are people coming to the site? What do they want to see on your homepage? People are coming to this site to read stories. That is why they're coming to the site. They don't want to see a message from the editor. They don't want to see a nice big splashy picture of the offices that you work out of. Not relevant. Users are coming here for stories. Make that primary. Again, this is the bits and pieces of a story we have to work with. How can we express that? What are the important pieces of that that we can show on the homepage? Let's whittle it down to the title, date, the section, program, lead text and image, and a share count so we know how popular story is. And let's define a way of looking at a story, a component that represents a story of a lead feature. And we're going to make it horizontally aligned. I'm going to show the title, the date, the section, program, lead text, lead image, share count. We've accounted for every piece. We have nothing in the design where we're like, so where does that actually come from? We know all of these are part of the content and that's something we can calculate. We know these sort of things. We know the content of the design to look pretty. That's not actually going to be usable. What's another way of looking at it? How about this squared feature design? Here, we're still showing the same title, date and section, lead image, share count, but this time, no lead text. All the same pieces from the content. We still know where all of this data is coming from. All of this content we can account for. We're just showing it in a different way. That's story object, the story content we have. Can we look at it another way? Sure. Illustrated lists. Same idea. We're going to show the same fields, but show it horizontally like this instead of vertically. Again, all of these pieces we can account for. It's the same pieces of content. Every one of these cases. In some cases, we'll have less space. In a compact version, we just show the section, image, and title. And we drop off the other pieces. But we still know where all of this content is coming from. It's still the same content powering it. And finally, it can go even smaller. It's hard to read from here, but you don't need to. It's just title, date, section. All of these are just different ways of assembling that same piece of content. They're different lenses on to that same piece of content. And we have designed these individual components which we can now mix and match. We can now assemble these into a complete page. So we have our lead up here. We have our smaller square features here. We can go down the entire page, in fact. This is the entire home page. And we have that lead image or lead feature that we designed. We have a couple of these square features, all the same design, just different content in them. We don't do custom design for each article. We've got our Illustrated List Compact here. We've got the full Illustrated List here. And that's the entire page. This entire home page is just a bunch of stories shown in different ways. Just showing the same content in different ways over and over again. This gives us a lot of flexibility. We can pour whatever content we want into the site, and this design will still work with us. So here are the various pieces. That seems like a lot of work, but it gets easier. In fact, the more you do it, the easier it gets. Let's look at a listing page. Say the landing page for a given section. So the Politics and Society section of the site. And all right, we've got some custom header stuff here for that section. That's going to be the same for every section. But notice this looks familiar. This looks familiar. This is the exact same component as on the home page. This main body area here, that is an Illustrated List. The design for that section is exactly the same as the Illustrated List on the home page. That means it's less work for you to design. It's less work to implement. It's less work for content editors to think about. And it's easier for users using the site. Oh, this looks the same. It probably is the same. In fact, it is. And then there's our especially Compact List over on the side. And we even have down here our Compact Illustrated List as well. The same components just rearrange differently, give us a completely different template. But we still only have to do the work of styling each of these once. And I'm sure some of you are wondering what are we talking about Drupal for? Why are we talking about this for? What does this have to do with Drupal? Well, what is Drupal? A content management system. Building systems is what Drupal is really, really good at. That's why we use it. We're handling a bunch of HTML pages like it was in the 1990s. Who actually wants to go back to the 1990s web? Didn't think so. For the type and color treatment, Drupal doesn't actually care. You have pretty much complete freedom here. As for your content, Drupal knows content. In the fancy lingo these days, this is content strategy. Understand your content and what you're trying to do with it. Understand what your users want out of it. This is actually really, really close to what we were just talking about. The story, as we model it in Drupal, looks an awful lot like what we had in the design. In fact, these should be designed together so that they complement each other. So we have that parallel between what we're going to model in Drupal and what we're showing on the site. Those need to go together. If you have a bunch of stuff on the page that has no corresponding structure in Drupal, how are you going to fill in that content? You're not. So don't set yourself up for that. How do you map this out in Drupal? Good planning. At Palantir, we've developed something we call the build spec. It's basically a very structured Google spreadsheet that we use to pre-plan all of the buttons we're going to push in Drupal. Drupal makes it really easy to plan out a content model by pushing buttons. Slides will be online later so you don't need to write down the link right now. But you want to plan out what you're going to be doing. You want to plan out what structure you want to build in Drupal before you actually push buttons. It's much easier to change before you start pushing buttons. So build spec, as I said, it's really just a glorified spreadsheet with some automation in it. So in this case, these are the various fields that we're going to define and their settings. We can think through, oh, should this field be multi-value? Yes, no, maybe. That can sometimes be hard to change after you start entering content. Think it through first. Do we want to limit this text field to a certain number of characters? Do we want to allow certain types of images in this image field? This lets us very, very easily think through and say, what does the design need? What does the content need? Therefore, what do we make Drupal do? Then map those into our content types. In this case, we have a basic page, general page, and then story. Story has these fields on it. And then we can push that into Drupal. Once you have your build spec defined, there are actually people who have built automated tools to partially just import that spreadsheet straight into Drupal. But you can do this in an afternoon of button pushing once you know what buttons you want to push. So we've got our title, date, section, our lead text, body text, lead image, and so on. Note we're separating the lead text and body text. We almost never use the built-in split teaser and body that Drupal uses. Honestly, I think that's a terrible thing. It works for blogs and basically nothing else. Give yourself the freedom to have a completely separate text if you want to. If you want it to be the same, users can copy and paste a bit or you can do other trickery with it. But make that independent. And then you get your nice ugly Drupal 7 edit form. But with all of those same fields on it. So there's our image, body, and so on and so on. So now we've got our content structured defined in Drupal. And we can start entering content now, at least we hope not. We can start entering content while we're still building out the rest of the site. As long as you have your content model figured out early. That's the important part. All right. Now that we've got our content, let's start building those components and those templates in Drupal. Can Drupal do that? Well, yes. A component, we just described it, is a visual representation of your content. Visual representations of content in Drupal are these things called view modes. So a view mode is a component. Huzzah! Not called that, but pretty much. You can configure a given view mode in Drupal. I want this field to show this way. I want its header or not. I want it to show this image. This particular size. I want it to have a link or not. You are defining a component here. You are defining a window onto a piece of content. Each of these... You can think of each of these fields as an element. Sometimes a bit more complex than that. It does a lot of markup, but conceptually, element, component. Some fields we can even hide entirely, like the full page version. We're not going to show the lead text at all. Period. And then that shows up on your page. This is news from tomorrow. Let's look at people a moment. And all those components are here. And this component is the full page version of your article. And add some CSS and HTML. I'm not a front-end developer, so I'm not going to show code for that. But you can have a template that targets a specific view mode. In this case, node in a full mode. You can also target a specific view mode and a specific node type to add CSS to taste. And you get the design you want. Here's your component. We've used Drupal to say these are the fields to expose to the template. Then we've used our template and our CSS to design it out the way we want. To make it look visually the way we want. And keep doing it. Who's worked with image styles in Drupal? Most of you. Image styles are pretty much exactly the same as view modes. Just for images. The same concept. Given this image, what lens do I want to use on it? I want a lens that says scale it to 145 by 82 pixels. I want a lens that will reduce it to grayscale. I want to lens that whatever. And you just create these image styles, view modes for images that you can then use. You can then define your own view modes. Drupal 7Core does not let you do that. Drupal 8Core does. In Drupal 7, there's a module called EntityViewMode from Dave Reid, because what isn't from Dave Reid? That lets you define custom view modes in the UI. They're all exportable. So we'll create an illustrated list of view mode that applies to stories. And we'll configure that view mode of this illustrated list to show the section, date, lead image. In this case, the image is going to link to the actual content itself. We're going to use that illustrated list image style we just defined. And we're going to hide the image caption, the credit, the body, and so on and so on. Tip. If you're showing an image as part of content on its own page, don't make it a link if it's on any other page. Make it a link, because I guarantee you users click on pictures. So make the picture go where they probably mean to go, which is to the content. So now that we have this lens, this view mode on our story called Illustrated List, where are we going to put it? Well, we can theme it the same way as we themed the full page version a moment ago. We just have a template and CSS that goes with it, and that applies to that one chunk of content. How do we get that onto the page? Everyone's best friend views. Views is a design tool. Never thought you'd hear someone say that, did you? Views is a design tool. It is for content assembly. It is for taking content and building it up with business rules. What are those business rules? Depends on your site, up to you. You can tag it, whatever. So not everyone realizes it, but in views. By default, views pulls out individual fields from a piece of content. But you can change it to show the entire content in a certain view mode. So let's make a view of Illustrated List representations of content. And now we can't specify individual fields because we're going to show the entire piece of content rendered in that way. And we're going to show a specific number of them. Let's say six. And we're going to filter it to just show published stories. And we're going to show them chronologically. You want different business rules? You push different plugins. But there you go. We have now assembled a view of content, a view of story nodes that will be shown in Illustrated List format. We've already defined Illustrated List format, and so it ends up looking like that. And here's other stories rendered the same way. Sometimes people ask about performance. Does it cost more in performance to load the entire node? As of Drupal 7, no it doesn't. Because if you are pulling even one field other than the title, views will do a full node load anyway. But it's going to load all of the nodes at once, because it can do that now. So the performance is basically going to be the same either way. If you're showing a single content type, there is almost never a reason to use fields. Pretty much if you're building a table is the only reason. Otherwise, view modes is a much more sustainable way of building a site. So now that we've got that view defined, how do we build that together into a page? I look at these designs, and the first word that comes to mind is panels. Not everybody likes panels, but panels is excellent for this kind of work. Panels is an excellent design tool. Because here I've got a view of, let's say, stories with a certain flag, chronologically limit one. Shown in the feature item view mode. Make a panel pane out of that, stick it into a panel. Here I've got a series of stories shown in the square feature format. So I have a view that pulls out, say, one from each of these sections, and I place those onto the page. Here I've got the illustrated list compact version. Depending on my business rules, I could make this one view or six different views, whatever makes sense, and put that onto the page. This, it's a list, of course it's a view, that I can put onto the page. I look at this and say this is trivially panels. The section page, same thing. This is that same view. It's the same view showing the same view mode as we had before. This is just another view. We want different logic here for, say, this pulls from all sections, this pulls from one section. Okay, we edit our view, creates two different displays, get them slightly different rules for how they filter, but they're still the same thing. What about performance? All these views we're loading. One of the nice things with panels, you can cache any of these independently of each other in panels. So you can make this page really, really fast and really, really easy to build and really consistent and easy to assemble. What happens if we want to make these responsive? What's going to happen to this page when it becomes responsive, when we need to try and shrink it down? Do we just do another design? No. We've already broken the site up, already broken the page up into pieces. The markup and the CSS for this illustrated list component. Excuse me. It's probably going to start looking ugly at a different size than these are going to start looking ugly. So when that particular piece gets too small, we use a media query breakpoint on just that piece and reformat just that view mode. And these will then break at the same place. Maybe at a different place we want to break this list into two. So it's three and three instead of six across. Is that going to be the same place as this? I doubt it. Are we going to want to move these around? Maybe hide some of them at different breakpoints? Probably. Same as these? I doubt it. Will the overall structure of the page break and start to get ugly at the same size as all of these others? Almost certainly not. With component-based design, with design system, we can say this piece has these breakpoints. This piece has these breakpoints. The entire layout has these breakpoints. And the site will just work itself out. Designing the browser really helps for this. You can just say what is the design going to look like at a given pixel size? I don't know. Every individual piece will do its best to look good. And the overall layout will do its best to look good. And so we may have effectively then 15 different places where the design shifts depending on the screen width. And they all look good. And we didn't have to design 15 different versions of the site. We designed one version of the site using components. Using individual view modes, using individual pieces that we can assemble and move around the page. How about when someone goes to create a new type of page on the site and they want to have a list of articles on it, a list of stories. They can use views and slap a new illustrated list into that page with different logic. And it looks good from day one. You don't need to go back and design a new page. You just assemble it out of the pieces you already have. I want to change the layout of the homepage and say I want to feed up at the top. Okay. Just move stuff around in panels. Everything still works. This is the power that components give you. You can rearrange them. You can have them respond differently to the environment independently of each other. For the developers in the room, decoupled components. Same concept at the design level. Independent pieces that you assemble into a greater whole. In short, Drupal is a very designer friendly CMS if you are designing in systems. If you try to design whole pages as a big image in Photoshop and then map that into Drupal, you are in for a world of pain. I have worked with a lot of designers who try and do that and I am in for a world of pain. And I don't always get the ability to make them feel the pain instead. If I have designers that can think in systems, it becomes really easy to build a site in Drupal. Drupal is a very design friendly CMS. It's just picky about who its friends are. Most importantly, understand your content. Abstractly. Don't think of your content as what appears on the page. What is a story conceptually? What makes up a story conceptually? That content model I can now express on a page. You don't start with the picture. And then make a picture of the content. More information on this is blog posts. I did a couple weeks back. Goes into this in a lot more detail. Again, slides will be online shortly after the session. I'll be tweeting them. If you find that it's hard to build a design using Drupal, it's not actually Drupal's fault. It means you're not doing design systems. If you're not doing design systems, you should be. Welcome to 2015. Some executive wanted this thing to appear on the page and didn't explain why. You don't know why? Well, that's because it's a bad design. If the design element doesn't fit, it doesn't match to your content, yet probably don't need it. And the executive, you need to be able to tell them, it doesn't actually fit the system. Because it's pretty, it's not a design system. We're not making posters. We're not making paintings. We're making content-driven websites. A system is a system. It is a series of components working together to form a complex whole. You want to use that same system for the entire project. The designers, the site builders, the coders should all be using that same mental model, that same design system, that same ubiquitous language across the entire site. You want to use that same system collaboratively. Do not have the designers design something and drop out on the desk of the developers and say, here, go build this. That never works. Does that ever actually work for anyone? Does that work well? Didn't think so. If the designers and the developers are working together, though, they can create a design system that mirrors the content structure by slapping some CSS on it. That becomes most of your job is push buttons and stop some CSS on it as you can go home at 5 o'clock and hang out with your friends or with your family, rather than staying there all night trying to make this design pixel perfect because the designer thinks that some home matters. Isn't that what we all want to go home at 5 o'clock and hang out with our family and friends? I agree. Thank you. We've got a fair bit of time for questions. We'll run a microphone around. Back there. Great presentation, Larry. Is there an easy way to get Drupal to give me a list of one node rendered in all the different view modes so that my CSS designer doesn't have to go and try to find them in all the different systems? I do not know of one off the top of my head. There is something called the style guide module which it doesn't work at that level. It gives you an unordered list, a paragraph, a table, an ordered list, and all those pieces so you know, oh, I forgot to theme the message box. I should go do that. I don't know of one that gives you all of those view modes, but it doesn't sound like a hard module to write. That would actually be really useful. Thank you for volunteering. Someone's already working on it. We'll hopefully have a buff at the codes. In our company, we start the project with requirements after that, a wireframe after that prototyping. We evaluate the user experience and after that we start the site building. And I believe that in this state it's very important to define the old development. I would like to know if there is a methodology to do this, to develop or to make the site building in a better way. Can you repeat the last part of the question, please? If there is a methodology to make the site building in a better way. How do you convince people to work this way instead of design and then dump design? I am talking about our process. We started with the functionality features, requirements and after that we start the wireframes and after that we start to evaluate the scenarios using prototyping. Okay. After those processes we started to define how can we model that in Drupal and use a site building methodology that we developed. Okay. I would like to know if there is a methodology to develop a good site building. Sorry, that last sentence I'm having a hard time understanding. I apologize. All right. Is there an established methodology for this kind of philosophy applied for site building? Okay. What we do is the build spec and that is something that ideally is a collaboration between the development team and the design team. So whoever the designer is is thinking about content and thinking about fields as they are putting together the design. They are thinking about this view mode of this content type. They are thinking about that as they are designing. And then we can model that in the build spec and then give feedback right there and think, all right, mapping things out in the spreadsheet we've come up with this question, this question, this question and this makes no sense at all. Go back to the designer. We haven't touched Drupal yet. Go back to the designer. Here's the potential issues we're seeing we want your feedback and you want that feedback loop between the development team and the design team. And then once you've got that figured out dump all that to Drupal. That's roughly the process that we follow with Palantir. The question for the recording is are we working with in-house design team or outside design teams? We do a little of each. When we have an internal design team we go through this process and it works out very well. I actually like working with our in-house designers. They get design systems. So other times we are working with an outside design firm and we have to factor in the operational time to reverse engineer their design and try and figure out how to map it into Drupal and it's almost always a poor fit. The designers, even if they are separate companies, designers and the developers should be working together from the beginning. If you have, designers go off and make design and give that to the developers. It doesn't matter if it's one company or two you will have problems, you will have a disconnect. Guaranteed. We have a design team and a third party design company because we have a tighter feedback loop and can have that kind of interaction to figure these kind of things out. Over here. Follow up on that. When you are not working with your internal design team you have a process of governance model where you suggest everything to be done in advance by the creative agency in a way that you are going to maximize this when you finally get to the point of designing and using Drupal for that. It varies with the client. Sometimes we have the ability to push back on the design and say one common line I like using if we have this piece on the page here this is going to take 40 hours to do. If we move it here that will take 2 hours to do. Client, which one you want? Sometimes we can do that, sometimes we can't. Sometimes the client will want the 40 hour version they may not want to pay for it but they will want the 40 hour version. Other times the designs have been approved by 5 levels of management before we are even hired and then we have to take the time and reverse engineer the designs and that is unfortunately something we have a great deal of experience in but that would be a totally different talk and I am not even the best person to give that talk. A lot of it comes down to looking through the designs finding the commonalities and saying this thing and this thing look almost the same let's assume they are the same and that is the same view mode and depending on the design that could be fairly simple to do, it could be really hard to do that really varies widely we had a project where we were given 5 or 7 designs and the themeers on the project took maybe 4 days to reverse engineer all of that into what are the design components we are going to have we had another client that dropped 180 PDFs on us it took a lot longer than 4 days to figure out what to do with that I wish I had a magic bullet for that one the only magic bullet is work with the design team from the beginning microphone Have you found the use of living style guides a part of this method a part of this workflow living style guides we are using those more and more like the tiles thing style tiles and stuff like that that's not a formal part of our process but we have used those at various times again it depends on whether we are doing our own design or building someone else's we are actually experimenting recently with using a static site generator as a prototyping tool and now that Drupal 8 will be using twig there are tools like Sculpin that is a static site generator for PHP that also uses twig so we are actually working right now to try and come up with a set of twig templates for Sculpin so we can do a lot of that prototyping in the actual code that will turn into the Drupal site that's something that is still fairly new we are still working on that but it looks promising hopefully in 6-8 months we will be able to present on that hi we do code branching is a very important part of our development process how would you integrate branching with this methodology branching is in like different branches for different parts of the content built out my honest recommendation for that you start the project when you spin up the Drupal site you do all of the build at once for everything you can just button push coming out of the build spec at once dump it all the features and that's sprint one so if you do this kind of planned out approach I recommend don't do agile for building out the content types don't wait and build out content types over time just build them all at once when you do that because you can think it through and realize oh this field here I can share with this content here and then that will make it easier to build views out of them for example so we don't always do this but my recommendation is the last Drupal project that I was on from the beginning our deliverable at the end of sprint one was the content model and a fully built site with all the buttons pushed, all the views built panels laid out, all the content types defined with some dummy content using bardic our frontend team was working on the theme separately but our actual deliverable was just we did the site build and then you can iterate from there and then tweak the views tweak your panel layouts and so forth always always always dump it to features which also means one person dumps the features because features doesn't like it when multiple people edit the same thing at the same time in different branches it really doesn't like that the actual solution to make that better there was a talk in here earlier on the Drupal 8 configuration system I'll be talking about it tomorrow during the keynote as well that's the real answer is to use that for now do the whole build at once use features for everything where possible and if you need to modify a feature only one person touches them at a time not to derail it too far but no mention of UX in this design process so if you could address that or what do you guys do I skipped over why you would want to lay out an illustrated list in a certain way that's where the UX comes in what different styles do you want to have should we put one big story on the front page or 50 small stories that's part of the UX that's a hardcore design topic so I'm not going to get into that too much I don't actually work in that field anymore I used to but I haven't in a long time so I'm skipping over a lot here about the designers doing the kind of UX thinking and alright we've got these story objects how do users want to use them do they want to see short versions they want to see long versions are we going to have two different versions of the title short title and long title maybe in some cases you will and then in your list versions you'll use a short title on the page itself you use the long title completely legitimate thing to do if that fits for your usability mostly here I'm looking at the components that come out of that process and how you're going to assemble those but absolutely thinking through why we want to give a design component what users are going to get out of it is a pre-represent for now that I'm talking about here any other questions? speak Spanish I will try to speak good English I think I have a translation here let's see if it works okay basado en tu experiencia cuanto que es lo recomendable que debería durar el proyecto de diseño de un sitio web y cuanto a tu empresa le cuesta el proyecto por proyecto cuanto le cuesta ser un pues manejar toda la parte gráfica the translating team is really good so the question for the English speakers in the room is how long does this take and what does it cost basically that can vary widely if the client you know we start working on a design and the client wants to change things eight times it'll take longer if they have very specific requirements around you know five different people have to sign off on it it'll take longer if you know they have a content model that makes sense from the get go it can go fairly fast I would say the overall appeal into our projects tend to last three to six months once contract is signed that can vary widely depending on you know if we're doing discovery whether or not we're doing design if we're doing discovery and design and the client doesn't actually know what they want that can be six months on its own or it could be a month and a half if the client is responsive so it's really hard to make a general statement about that as far as cost I don't have a breakdown of what this part of our project would cost but I will say it's cheaper than trying to shoehorn a bad design or non-systemic design into Drupal at the last minute it saves you a lot of time and a lot of aggravation in the second half of the project to do this kind of upfront thinking even if the design is weird and doesn't really belong in Drupal do this kind of thinking upfront and you can make it work and I have had designs that I look at like why are you even using Drupal in the first place but by using this kind of process we can make it work and no one had to stay in the office until 9 o'clock so I can't give an exact answer but on the whole doing it this way saves money over not doing it this way over here a couple over this side hello Larry I am the menu the menu man do you remember yesterday okay okay I didn't talk about menu here at all actually no no my question is do you recommend more this thing you said is better to use a template 100% or is there a kind of percent with templates or design from zero from the paper and the design tools for example so when you say templates do you mean stock form of a page for the client for the time you recommend that 100% or that really depends on the client most of the clients that we work with at Palantir wants a very custom design so we don't really have much in the way of pre-built templates that we will always go to unless you tell us otherwise that's because we work mostly with large institutional nonprofits universities, museums, hospitals if you're dealing mostly with small businesses then having a set of stock templates you can pour design objects into can be a big time saver and in fact panels lets you define additional templates they call them layout plugins which are really just a template and attached to TSS so if you have a collection of those pre-built you can use those and then try and steer if you control the design you can steer towards that to save money what about the client for sometimes they wanted original design what is the difference or the advantage from original design that also can vary you can do something that has a very unique font and color treatment but uses a very traditional layout most sites honestly most of the pages are blob of content in the middle stuff on the side, stuff on the top that is most sites so for example we use the zen grids theming system the zen base theme for Drupal and it comes with a bunch of panels, plugins that are fully responsive out of the box we usually go to those first we can write new ones but very often that will be enough and then by focusing on the component and make the component look good for that client and make the font and color treatment unique to that client it's still content in the middle stuff on the side it's still most pages and so we can save time and money that way but it's really hard to give a generic answer so widely by the client some are okay with just pulling a commercial theme off the shelf from companies that sell them ours usually want a very custom design so that's what I'm used to thank you this is our last question from your experience what do you think Drupal is missing a better design system what is Drupal locking when you do some system like this I'm not sure I followed the question from your perspective what could Drupal do better I will list two things one is be much more explicit about its support for these tools image styles and view modes are conceptually the exact same thing but we don't talk about them as the same thing we don't talk about design systems we don't explicitly build for these tools this is kind of an emergent of design in Drupal it's not something that anyone sat down and deliberately built a design system friendly CMS it just kind of evolved that way and I think starting with what's consciously and explicitly acknowledge this approach and push view modes more on design components more unified the terminology between image styles and view modes things like that I think could help the other and we tried to do this for Drupal 8 we didn't quite make it but it will be in contrib is build panels directly into core one of the things that makes panels annoying and difficult to use in Drupal 7 is it hacks around cores internal design the internal design in Drupal 8 has changed dramatically in a very large part to try and make it easier to do what panels does we did not get as far with that as I would have liked there's still a lot of pieces of the way Drupal works internally that don't quite fit this model but can be bent to that model I would like to see us try and just make this approach of design components pulled into a template explicit and a very deliberate part of the architecture as deliberate as I think it should be but that's for 8.1 or Drupal 9 thank you all for coming enjoy the rest of the conference