 Hello. Welcome to our session. And today we are going to talk about prototypes. So it's in front end track. And the presentation has several parts. So one part will be about front end, and another part will be a little bit about back end. Actually, how to communicate to your back end developers about ideas we are going to talk about. But let me start with the introduction. My name is Yuri Gerasimov. I'm a back end developer. Currently I'm working as architect, team leader. And this is my colleague. Hey, everyone. My name is Morten Kristofsen. I'm the user experience lead at FFW. And just a quick introduction to FFW for those of you who haven't heard of us before. We're a global digital agency. We have offices across the globe in 11 countries from US to Vietnam. And we're a full service digital agency. We have about 420 full time employees and about 20 offices worldwide. So as Yuri just said, today we'll be talking about these four things. So there's kind of two parts to this presentation. The first part we'll be talking about is designing in browser and prototyping. So I'll kind of be walking you through designing in browser. What is it? And why would you do it? And I'll be talking about the prototyping setup that we're using at FFW for our designers. Then Yuri's going to take over from that and talk about how we work with implementing prototypes in Drupal 7 and also a bit about Drupal 8, what to expect next. So between each of these four sections we'll have some time for questions. So we don't have to kind of add everything on to the end because it's a lot of ground we'll be covering today. So designing in browser, what is it? And why should we even do it? So I'm going to start off with the what part. So designing in browser essentially means designing websites directly in the browser using HTML, CSS, JavaScript. Instead of using apps such as Photoshop or Fireworks or Sketch. So let me expand a little bit on that. So for a long time, designing websites has been about creating static mockups. So mockups created in Photoshop, in Fireworks, in Sketch in this instance. But designing in browser really is about replacing these static mockups with designing directly in code. So designing directly in the browser with HTML, CSS, JavaScript. So in the industry as a whole, in the web industry, there's kind of been a general trend among designers to begin kind of learning some of a bit of coding and kind of moving in this direction. Probably a lot of you in here are familiar with this trend. Maybe a lot of you are already working in this way. And at FFW, it's kind of a trend or an approach we've been moving towards for the past couple of years, really. So the way we work with it is that we have our designers working closely with front-end developers actually writing up these prototypes, hand coding them in the framework that I'm going to be talking about a bit later. So with actual code written by hand that our designers can kind of hand off to our front-end developers and hand off to implementation. So obviously, this is a new technique. And it has kind of new requirements for designers, new requirements for the workflows. But it also has kind of a ton of benefits beginning to kind of bridge the design and code. So that really brings me to the why. So why would we want to do this? We have this perfectly fine process that we've been working with for a long time. Why would we want to begin mixing up front-end development and design? So I have four benefits that I want to walk you through today. So why would we want to design in browser? So those benefits are precision, consistency, interaction, and transparency. So we'll get started with precision. So when we design a responsive website for a long time, it's been about designing these nice pixel-perfect mock-ups in probably around three sizes, maybe more, maybe less. But yeah, designing like a mobile, tablet, desktop size is a pretty traditional way to do it. And it works nice, but it also has a lot of limitations, because the challenge is that we don't really know what's going to go on in between these different break points or really these kind of images, screenshots of the overall experience. So the challenge is that all of these things that developers have to kind of take into account when they have to begin to implement designs. So things such as is this actually a responsive design, or is it an adaptive design? Are we using relative units, or is it a static unit? What kind of break points are we working with? Is it like a max-width site, or is it in like a fixed-width container? And also like the flow of the content. So I've not been guilty of this myself, but I don't know how many times I've seen designers design these perfect mock-ups with these like fixed height elements, and then you throw like an extra line of text in there, and it just breaks the full layout, right? And the designers get really mad at the developers. And all of these factors are something that we need to take into account, and something that designers like to have control of, but they usually tend to miss it with these static mock-ups. So what prototyping or designing in browser does is it kind of gives us the control and the precision over all of these details. And it also really forces designers to take these details into account about the responsive behavior of the things we're designing. So that's the first benefit of designing in browser. Let's continue with consistency. So as a designer on like a large-scale web project with the traditional approach to designing mock-ups, it can be kind of a challenge to keep track of all the components that you're designing and to maintain kind of consistency across our site. Let's just take a really simple example with a button. So it's pretty easy to design a button. You choose a nice typography. You put it in a box. And because obviously we've worked with web before, we know that it's a good idea to just choose like a padding. And it's going to work nicely even when we change the text. The problem is that in Photoshop or Sketch, it rarely kind of works nicely, even if you use kind of some of the tools available in those programs. It rarely works nicely once you start kind of iterating and the project grows and the iterations kind of pile up and the risk at least of introducing kind of inconsistencies in your design grows. So maybe you had to change the text on the button and suddenly these paddings are no longer what they're meant to. And so we start introducing these inconsistencies. And it takes a lot of time to clean that up. I mean, the problem, I mean, inconsistencies, you can get rid of those, but it takes a lot of time as a designer to go through all those files and clean all of that up. So one problem that also kind of arises then is that what if at the end of the project we decide that we wanna kind of add a border radius to the button, we wanna add rounded corners. Now we have to go through all of the files that we've used and we have to update it. And even if we're using something like smart objects or symbols in Sketch, we still have to go through all those files and export them again. So the good thing about designing in browser, about designing with code is that we were able to really easily introduce consistency. I mean, we just have all of our variables or all of our code in like one class for the button. And if we wanna add a border radius, well, we just add it and it automatically gets updated everywhere in the prototype. So it's really a way to kind of allow us to split all of these components that we're designing into these reusable components. So yeah, that's the second benefit of designing in browser. We get reusable styles, reusable components. So the third benefit is interaction. So designing with, designing digital products, designing a website obviously is about more than designing what it looks like. It's about designing how it works, it's about how it feels to interact with the website. That's the purpose of a website, in most cases, interaction. So we find that it's kind of a paradox really to begin to design something as dynamic as a website with something as static as a mockup. Because a mockup essentially is a pretty picture, right? And the problem with pretty pictures is not that they're pretty or that they're pictures, it's that they don't react, pictures don't react to users. So when we design in browser, when we do prototyping, we work with the interaction design of the solution. So we have to take into account how things we act to user input. We can work with that in various ways, but three ways that are really important I wanna walk you through now. So the first is user flows. So designing in browsers, designing in browser allows us to take into account the flows of the website that we're designing. So even though we can talk about it and think about it for a long time, do extensive information architecture, nothing kind of beats being able to actually use that flow that you're building. So is that user journey, is that logical? Can people find their way through that checkout flow that you've designed? With prototypes, we don't have to kind of guess. We can just, you know, test it, try it out. We're actually testing it all the time as we kind of go through the flows. So the second one is one that often in my experience tends to be forgotten when we're designing with static mockups. So things like feedback. So what does an error message look like? A confirmation message, a hover state, an active state, all these things that are really important to making an interface feel responsive feels like it's reacting to your input. And all of these things can be really difficult to get around to when you're just designing with static mockups, because obviously you don't use the static mockups yourself, you look at them. You don't try clicking that button. So you never, you forget that you need to add an error message until the developer tells you you didn't design an error message and we're about to launch tomorrow. Obviously Yuri gives me more of a heads up than that. And the third one I wanna walk through is transitions and animations. So probably a lot of you are aware that transitions and animations have again become kind of increasingly important in recent years. We're seeing a lot of it in web design today. And it is really important because transitions and animations allow us to communicate context to users. So allow us to communicate context about the various states of objects. Just something simple like clicking an image and having it open up in a light box or an overlay. How does that interaction work? Does it just appear right in your face when you click the image? Or do we have like a nice simple transition that just makes the user aware what's going on? Like we're opening up this image for you that you just clicked. So it's simple stuff, but stuff that's really important for the overall use experience and stuff that you can't really design in a mockup. So that's the third benefit interaction. The fourth one is transparency. And it's maybe on kind of a higher level than kind of the technicalities of designing and implementing. So maybe some of you have seen design processes that go something like this. So we have a client that gives you some kind of input that could be like a brief or maybe it's a workshop or it's some kind of research that's already been done. And they feed it to this design black box. So this magical black box where designers sit because designers are these magnificent creatures that sit in their own little universe and they come up with some magic solution and they just give it to the clients after two months of waiting. The problem is that the clients don't always agree with these magical solutions that the designers come up with in their black box. So to kind of solve this challenge, what we do at FFW with prototyping and designing in browser is that we from day one, we invite the clients into this design black box and have them be part of the design process. And one of the ways we do that is by giving them a URL, a link to the prototype from day one basically. So they can see as we're kind of building out the design they can follow along. They can see when it's broken. They can see when it's unbroken again and they can kind of follow along with the process. And it's really a nice way of also anchoring that project with the client. Another really nice thing about that is that the client no longer is kind of forced to looking only at the visual design, which they often do. They often put on the designer hat when they're just looking at mock-ups because that's what they can kind of relate to. Then they look at the details of typography, colors. Oh, is that background image the right one? I think we need to use the other one. So things that really doesn't matter in like a design process. They should be looking at the interaction and the flow of the website. So with prototypes, the client automatically becomes a user so they can go to that link and they automatically start using the website. So they interact with the interface. That also has kind of a nice added benefit which is related to the overall process. So traditionally design has been very siloed kind of in one end of a full process. And theming and QA has been very much siloed in the other end which puts a huge amount of pressure also on QA right before launch. And fixing stuff like small visual box sometimes can be down prioritized because there are more important things at the right before a launch of a project, right? But the good thing about designing in browser is that we kind of split this up. So the theming and design kind of overlaps really and development can actually start while we're still working on designs. And QA becomes much more kind of spread out because we're actually starting QA from day one basically. This should actually be from day one I guess with the client because they're constantly testing the website we're building for them and we're constantly testing it ourselves. So that's transparency. So that's the four benefits of designing in browser that I wanted to kind of present today. So we're gonna take a minute here for any questions. Yes. So the question is do we have any designers that do style tiles or anything like that to design on typography colors? And yes we do. So obviously prototyping and designing in browser is part of a whole design process. So we don't just start a project by designing in browser. We obviously have a process that goes before that by determining information architecture and business goals and all of these things. And as part of kind of starting up the design process we also do style tiles is one thing we tend to do. But we also work with mock-ups still. So I'm not suggesting that today that you delete Photoshop and sketch and all that stuff from your computers. But I'm suggesting that mock-ups should be meant for at the beginning of a project maybe doing two, three mock-ups of like a front page or some kind of idea to set the visual style. So to decide on typography colors and it can always be iterated on later. But it gives a nice sense of kind of security or certainty for the client as well to have seen just kind of some direction before we move into browser. But we only do very few mock-ups or something like style tiles works nicely as well. And then we move into designing directly in the browser. Yes, any tools for? Yep, I will get to that in right a second. There'll be a ton of tools we'll be talking about. Yes. So the question is do our designers know JavaScript, for example, to work with like animations and carousels and transitions? And the question is the answer is some of them do. So we, yeah, we have what we call them hybrid designers because they're kind of designers and they're kind of front-end developers and it also sounds cool. So that's an added benefit. But yeah, we have designers that do both kind of that are traditionally designers but that have worked more and more with kind of front-end technologies and that's usually HTML, CSS, and JavaScript. But we also have designers working with this process that have no knowledge of JavaScript but that just then get teamed up with a front-end developer or with one of these hybrids. So instead of having the one hybrid, you just have a team of two people working really closely together. So obviously it gives new requirements to our designers but also to the front-end developers that have to work in this workflow because they have to put on their designer hats as well and kind of be willing to iterate quickly with a designer. So it can work both ways. You don't need to find these hybrids. You can set up teams of a designer and a front-end developer that are kind of the design team at the beginning of the project. Yeah, so the question was what do you think about apps like Avercode that can generate code? So we've used apps such as that as well. There are a ton of them. We've used one called Webflow and still use that in some instances. And it can work nicely. The problem, and I'll get back to that with these kind of apps and why we try to get over to kind of hand coding with our framework is that at some point we have to hand it off to our front-end developers and we want to be able to reuse as much of the code base as we possibly can with that handoff. And obviously we could set up a whole process around something like Webflow but we don't want to do that. So we'd rather kind of have our own setup that kind of feeds into Drupal development. Yes? Yeah, so the question is does the client sometimes get too involved with this process and kind of want to decide the colors and I want to add rounded border radius to that button. So there are kind of two answers to that question. I would say one is that in my experience actually most often the opposite kind of happens. When we show mock-ups to clients they start talking about colors and typography. But when we show them prototypes they start clicking around and using it and they actually start talking about the things that matter and I'm a designer I still think typography and rounded corners matter but whether a button should have rounded corners or not that's not the important part of designing a website at all that rarely changes anything really in terms of the use experience. So often we find that they actually start using the product instead so that becomes the focus. So the other answer to that question is that instead of having the big reveal at the end we try to really get away from those big reveals because going into the black box and then you come out and show the mock-ups because when you do those big reveals you often get really bad reaction because maybe you've been working in a totally wrong direction and you basically have to start over. So by involving the client from the beginning they do become part of the process but it's also obviously then important to kind of set boundaries with a client that you have to do that basically and they know that as well it's in their best interest. So even though you're working closely with the client you have to still make sure that everyone on the team is aware of their role, right? So it's about educating the client, yes. I mean it's about making the client aware that they're paying obviously for your expertise as a designer or a developer and obviously you take client input into account but you have to just tell the client if they're suddenly putting on the designer's hat and telling you that button should have rounded corners or whatever and you have to kind of be able to set those boundaries with the client. So it's about collaboration and obviously there can be challenges. It's not always a perfect collaboration. It's not a perfect world but I think there's definitely ways to kind of make sure you don't get those problems by just communicating well throughout the project and prototypes really help with that, yes? Yeah, so as I was saying the question was can you tell us a little bit more about the communication process? So as I was saying obviously we don't start off with just designing prototypes. So it's not like we get a brief and then we call and we set up the deal with the client and then we just start prototyping. Obviously there's a whole process that goes kind of before prototyping. So we have all kinds of workshops and kind of meetings both on like a strategic level, figuring out business goals, figuring out user goals, setting KPIs for the website. All this stuff that you would inform your designs has obviously been done before this process starts. And then we also obviously do information architecture. We could do something like style tiles. So that kind of process goes before prototyping. But once we move into actually prototyping we tend to have kind of these rapid iterations. So we talk to the client at least once a week. We have like a meeting maybe two times a week. And we do this remote as well. It doesn't have to be an in-person meeting. So at least once a week we have meetings and kind of talk through the changes that have been done. So it's almost like continuous sprints. All right, so okay, so last question. Yes, sorry I didn't catch that. I think there's not like a clear answers to that. I think how this methodology came about. I think for like the design perspective it came about because we had a lot of designers that wanted to work with more and more with interaction design. And we had a lot of front-end developers that were kind of frustrated with not getting enough information about the thoughts behind kind of the interfaces. You can only read so much from like a user story or something like that. So by kind of moving our front-end developers and our designers closer together we've kind of been able to bridge that gap I think. So that's kind of what brought on this change in methodology. So we have to get moving with the next section. So I just wanna walk you through the setup that we're using right now at FFW and kind of some of the technologies. So we use these six technologies in the prototyping setup that we're using right now. And I don't wanna go through all of them right now. We don't have time to do that. But a lot of you are probably familiar with the Node.js and the Node.package manager. We use that for managing all our dependencies so we can just easily start a new project but just installing that. We have Bauer in there which is a package manager for front-end libraries which also kind of pulls in some of the dependencies we have there. We're using SAS as a CSS preprocessor. So it's kind of an extension to the CSS language that allows us to do things like loops and variables and stuff like that. We're using a grid system called SUSE which is a really, really great SAS-based grid system that allows you to do pretty much anything. It's really flexible and in our experience has worked nicely with Drupal as well. But the two technologies that I wanna talk about today are Gulp and Tweak. So Gulp.js is a built system and a task automation system that we're using in our prototype setup. And maybe you can't see it that clearly but what we're looking at now is the Gulp file of our project. So the Gulp file pulls in all of the different dependencies we're using and automates a lot of different tasks for us. So some of the things we're doing with Gulp is we're starting a static server with live reloading. So we're watching files for changes and running tasks whenever something changes. So whenever a file changes we're automatically reloading the browsers and you can open it up. You get like an external URL as well so you can open it up on all your different devices in the device lab and look at the site as you're designing. So we compile the SCSS files. We automatically add vendor prefixes. We generate source maps. We compile the Tweak templates that we're using to HTML. And we automatically include data with these templates. So that's all well and good but what's really important like the important point here is that Gulp is set up to automate all of this for us. So our designers really, they don't have to worry about this. That's the point because all of this is like front end technology stuff and we don't want our designers to worry about this. So this is all automated. So our designers only have to worry about this if something breaks. And thankfully, that doesn't happen too often. So it's a really nice, Gulp adds like a really nice level of automation. So the other technology is Tweak. And as you've probably heard here at DrupalCon, Tweak is gonna be part of Drupal 8. But we've been using Tweak as our template engine for a while and the great thing about Tweak and really any template engine is that it allows us to do all these kind of things like output and escape and filter data. It allows some kind of presentation logic like conditionals and loops. We can define and overwrite blocks and we can do includes and extend templates. So all of these things are things that again, the designers working with this, they have to learn. But it's a lot easier than learning like how to do these things in PHP. So that's really great. It's, that works nicely. So especially things like includes, we have an include up here if you can't read that. That's really important because it allows us to kind of split things into two components. So take the navigation out of there, just a really standard example. But something that really makes it easy for our designers to understand this modular way of working as well. We do things like extends. So we build a basic layout template with the head and any photo styles that are gonna be on every page. And then we just extend that. So when we design new pages, it's really easy to just extend that basic layout page and our designers can worry about building out the bulk of these pages. But the most interesting thing really is that it allows us to create these components. So it allows us to actually move away from thinking just in pages, thinking web design as pages. It allows us to work much more in kind of a modular way. So for every kind of block file we have, we can have also an SCSS file that kind of correlates with this. So we have to get these really nice modular, these components that it's really easy to also reuse later in development. And it's a nice way to think about it, that you're not designing pages. You're not designing 10 different templates, web pages. Obviously you're also doing that. But the way to think about it is to kind of break it down into a design system. So you're designing components in a system. Obviously that also allows us to do things like set up a style guide that kind of shows all of these various components that we've designed. And actually today the way we're doing it is kind of, I'm gonna call it semi-manual. So we have like a style guide file set up that outputs all of the things that we know we use in every project, like typography and these things. And then we manually add in new components that we're using. But there are some great technologies out there that can automate for it. There was actually a really interesting talk yesterday about KSS and KSS node and actually using that with twig to automatically generate style guides. So we're definitely looking into adding that to our framework. So to kind of sum up, I would say that all of this really comes together in a framework that works really nicely for our designers. So to kind of get started with a project, they just type gulp in the terminal. So they don't have to mess around too much in the terminal. They just type gulp and we're off. And every time they change something in the design, it automatically gets updated. And they just have to really worry about the SCSS and the twig templates and everything else kind of gets done for them. All right, that's the prototyping set up. So any quick questions before we move on to Drupal 7? Yep. So I think some designers find it more difficult than others. I think it really depends on where you're kind of coming from. But I would say obviously some of the major challenges obviously are that designers have to care about and learn some of these technologies, at least basic HTML and CSS. Obviously that's a new requirement and that's obviously a challenge because it's kind of a requirement in order to be able to work this way. I mean, you can work really closely with a front end developer, but you have to know at least a little bit about mock-up and styling. So that's a major challenge. The other way around, it's also a challenge to kind of make sure that everything is aligned and ready for implementing. Because obviously we need to involve the front end developers in the process as well and they have to care also deeply about the design aspect. So obviously I think the major challenge is bringing these two different kind of skill sets together and making them work together nicely. That obviously can have some challenges, but overall I'd say it generally people want to work together obviously to create the best possible solution. I mean, that's probably why we're all here. We like creating great websites. So I think generally it works out nicely. Yeah, so we've actually, obviously we haven't done that extensively yet, but we've done a few kind of test drives at that and it's working out nicely and Yuri's gonna talk a little bit more about that. Yep, last question here. Good question. The answer is it depends. But obviously we often start out with doing content strategy and defining content almost kind of simultaneously as we're starting up the information architecture and starting up with design. So we use as much real content as we can basically. So we do these includes JSON files with all of our templates. So we can just add in some data there and output it in the templates as well. But obviously there are projects where we're not able to do it that way. Just like it would be with static mockups. Sometimes you don't have that content available so you have to use placeholders and Lorem Ipsum and stuff like that. But it's not optimal. We prefer to use real content. So we might have time for more questions later, but I'm gonna hand it over to Yuri now. I would like to give some comments from developers perspective how usually project goes. So before we started implementation of this process, our team was really had this split like we kick off the project with the client and then designers comes in and then like in few months we are going to be amazed what is going to get into development. And especially when you have designers who are coming from non-website background like they didn't have experience with designing for the web. The best ones are from publishing where everything should be like pixel perfect and ideal. That's where trouble starts. So and there is another problem when we start implementing things is that front end developers, they just start screaming right away when they understand like what they get designs and when they get the data of the Drupal and they know what output of the Drupal is and like how much they need to work on the things to make them nice. So it's very good in this workflow when front end developers they engaged way earlier and they start telling back end developers like what data we need and how things are going to work. And what I will talk about is actually we were coming up with these ideas like way earlier like I don't know three, four years ago when we get these huge problems in the end of the project when we had front end developers rewriting the whole CSS files multiple times because they just grown like 10, 20,000 lines and it's like not the limit of course. And we were thinking like okay but in development we have also similar things like we can go really wild not thinking about the future and all architecture can be banned and that's what we do we rewrite or factor everything. So how to solve that issue. And this is something that we come up with but when after this talk you will start talking to a developers like 100% they will resist because the ideal scenario for back end developers is like here is your data like and now you make it beautiful and we don't care. This is the views you have five templates to write I don't care like you just have your own thing. And if you need some more data like no problems here's another view another block like just like we have all now a back end development performance like third party integrations we are too busy to handle that stuff. And no worries I'm not going to talk I'm not going to teach you some bad language how to speak with developers so they will cool down but there are some tricks in Drupal that make this little bit easier for them to understand like yes it's like completely different HTML but it's not end of the world and we actually can implement it and we did not say to client oh back end development is two times more so that's not going to happen. So some things that I will talk about is some modules and I expect you to be a little bit familiar about Drupal ecosystem about some modules that we're using. So we will talk about panels views some view modes about entities and JavaScript of course. So panels we have the standard we landed to be a standard using panels for all our layouts. And this is very handy because you can have a layout you have full control of it you can put some more blocks in different areas and it's very nice for developers pretty bad for clients to manage the site if you let them go to the panel's back end but still it's manageable with all these inline panels editor and all that stuff. What is important when you start implementing Drupal sites and you have these prototypes. So one of important thing is actually to do the inventory and this is something that actually good designers do they come up with style guides they have all these different kind of like these are the buttons these are type of buttons these are blocks these are layout sometimes so you can understand what kind of layouts you need to build in your back end. Another thing like what type of blocks you need to build because in the back end of course we have flexibility we can depending on conditions we can have either one layout or the other layout or one type of block or the other so we have no problems with that but it's very bad idea to create one block with 50 different types of output and same with layouts I mean it's fine if you have like one, two different layouts depending on condition for the same page but if it grows you really need to go for different layouts. And this is something that we start off when we start developing. So for example we have this kind of part of the page and like in conventional development what we say okay the bottom list is a view we can assemble the view pretty fast and then top left block is also a view and there is another block yes that's going to be paints and we are going to display everything with views. When we do the when we have prototypes we actually implement them as custom paints. So we display every single piece of the content as the custom paint to lower down number of templates. This is the key element of implementation because like if you think about views and you will need to implement some very fancy HTML that is very easy to theme but it's very custom. You will probably need to override at least three, four templates in field mode and when you will have like 30 views you need to do that you will have like huge number of templates and the whole idea of working with panels and views is actually and custom paints is actually to lower down those number. So in this scenario we would build also three blocks but each of them are going to be paints and we do use views but we render them in a little bit different way. For the panels when you create a custom paints these blocks what is important is that you need to use templates for every single time you do theming. So when you render something just please create a template. Like there are two ways of theming in Drupal you can either create a function somewhere in your code or you can create a template like please use templates. It's so much better for front end developers especially because they have tweak templates or they can if it's rendered as the HTML they can just copy paste and then change something instead of like putting that into your separate module file and then it should be somewhere in the code they need to find it. It's much better for maintenance. Another thing is when you create the custom paint please place the template files inside of the folder where you actually prepare the data for that paint. So in that case you understand like okay I need to change that paint a little bit the output I go to the panels interface I know the name of that paint and then immediately in the code I find both where I prepare the data for that paint and where I render it I can see the template. For that, oh maybe you wouldn't be able to see this. So the trick part that is like documented but not that well in a plugging definition of your content pane you need to identify the hook theme and then you can tell the Drupal the template file is in the folder within the same file of pane definition. Probably this is something that you should point to your developers too when they will start working with this thing. And regarding views, views are great. They are very flexible. We really love to use them but rendering like we try to keep our self out. So in the custom paints we just execute them to get the results but then we render them in the way we like. So in this way this is some snippet of the code that we use. So when we need to have your results we just execute them programmatically. We get results, we actually load the nodes when that we were getting as results and then we theme them with node view function. So that is another trick that we found very handy to avoid all these multiple templates in theming views. Another thing is display modes for entities. So entities, let's talk about nodes mainly. So by default nodes in Drupal they have full view, teaser view, RSS search but like not that many, right? And in our real life websites when we have lists we have multiple types of lists with different type of HTML. I mean the same node can look very different in different lists. So this is where we try to use view modes and that means that in the list we just create a new type like it can be teaser archive or teaser search or teaser listing news or something that will identify what listing this content is going to be displayed at and then we just have separate template per each list. It's actually very similar that you're going to build in prototypes. You're going just to use the same template for all of the listings and this is what we are trying to use as well. So in this case of course the number of templates will grow but they are still pretty easy to manage because you know how you name the templates, you know okay this is the, we usually name them like node and content type and then some kind of identifier where the list is. Usually it's like views name. So in this way we can easily find the template for that particular view. And it's very important to also keep very good order of your templates in your theme. So what we usually do, we have template folder in theme and then we have different type of entities like file entity, fillable panel paints, nodes, it can be taxonomy terms like different types and then we go with even more elements in hierarchy. In this case it's article like content type. So you will come up with your own system that's for sure but this is very important to think upfront before you start developing. JavaScripts, this is something that gets pretty tricky if you let your front end developers to go too far because like they will like to use some fancy JavaScript frameworks that Drupal has no compatibility even. What we try to do, because the front end developer will take responsibility for delivering the project, they need to remember what versions are like jQuery, what JavaScripts in Drupal should be available and they shouldn't conflict. So as the general rule we ask front end developers to remember include Drupal GS, this is the one that use Drupal behaviors and also wrap all the JavaScript they built in Drupal behaviors to be at least closer to be compatible to Drupal code. It doesn't mean that it will not change, it will definitely change, especially if there are some things like Ajax that you use like core framework for the Ajax calls and all these forms auto submits. This kind of things usually get rewritten when they start being implemented in Drupal but still when you have at least these basics code will be much better shape you will not need to rewrite that much. Some advantages of prototype based approach when you're not using Drupal. So we had experience of building website like part of the website in Sylex and Sylex is the micro framework built on symphony components and some others. And it uses tweak and it was like a miracle for us. Really, we just like grab the templates from prototypes, put them in Sylex like little modification there like in two, three hours we were able to assemble the whole page with all the data with everything. That will not happen probably in Drupal in nearest future but if you are planning to build something in other systems prototype based approach is even way better than designing Photoshop. It just like works. If you have tweak support, of course, Drupal 8. This is something that we don't have like real life experience. We just starting working with Drupal 8. Things that we know will be more better to support this model is of course tweak because we are going to use the tweak templates. I have huge doubts about using them as is. Probably we will need to modify them and it's still not known for us what is the template structure in Drupal 8 going to be. So I think after couple of projects our way of prototyping will change. So it will change the structure so it will fit closer to Drupal structure but this is something where collaboration will be great. JavaScript, Drupal 8 supports more modern versions of everything and it has like backbone and other things. So I think it's really will be much better but I'm very eager to start some Drupal 8 projects and experiment with them and update this slide. This is it for me. Do we have any questions? Yes, please. The question is about the way we serve pages. Panel panes. So when we assemble the page we have two things. So the general layout is usually controlled by panels everywhere. So it's like the first part. This is where I usually have like head of footer, right? The second level is actually panels and it can be either panel pages or penalized nodes. And then when we go to the paints, actually all of them are usually custom paints that we define in the code. So we don't use anything, well, we use but it's very low. We don't use much of the things that coming from the panels themselves. We don't use like standard paints from panels or page manager or C tools. We just build them in order to control the templates. Does this answer? Okay, so for the content editors, they find this set up really great, like no jokes. Like when we start giving them penalized nodes with multiple variants of layout, like you can do in penalizer, and also they can go into like edit mode and add any paints they like and they know which paints are there and we also can limit the options. They find it like, yes, it's the best CMS ever and thumbs up, it's so much better than all things we had previously. So it works really well. Also, of course, it's a matter of education because you give more flexibility to the customers. You need to educate them not to put the huge block in the sidebar and it will crash the whole layout. But in general, it's a much more flexible approach and clients really appreciate it. Yes, please? So performance, like theoretically, right? Views got several elements in the pipeline they're being rendered. So the first one is actually execution. And this is what we do in custom paints as well. And then we go into, and we have a cache based on execution, we can cache results for the viewed bending on arguments and so forth. No, it's in views configuration, we don't change that. And then we have a view rendering and we skip all that part. So instead of collecting and discovering like what templates to use and there are like four or five of them, we don't do that at all. We just render it from one thinning function. So it should be more performant. Also because it's custom paints, also because it's custom paints, we still have all that granular control over caching. I mean, if there are anything that is going to be slow, we will control it from our caching and we can purge it ourselves. So like performance tuning is not the issue because we have a lot of custom coded controls all the elements. Yeah, panels, performance, yes, but it's still, if there are any troubles, we have knowledge we can add layers of caching. So in our experience, we didn't have any performance issues with using this approach and it doesn't matter whether you render just a view in the panel. I mean, panel themselves can have some issues. Views themselves can have some issues but we don't skip any caching layer. And if we even skip, we can easily add the other questions, please. Yes, please. So why we use view modes of entities, right? Instead of fields? So the question is why don't we use display suite for rendering view modes? And instead, we do that in the code in templates, right? The reason is for maintenance, for more convenient changing it for front end developers. Because if you have some configuration in display suite, yes, you have layout, but you also have what fields are there and how they're going to be displayed. If front end developer, for example, will need to change the order, he will need to find that element in display suite to change the order. He needs to make sure, maybe if something small changes, he need to go to layout. So there are like multiple places where you control the way it's going to be displayed. In our case, we decided just to go with plain templates because it's something that they are already using in prototypes. And this is where things just click together. And I mean, if your front end developers are comfortable with display suite, I mean, it's great module, like use it. We have decided to switch to like more templates, but it's still manageable and everyone understands where to find them. Yes, please. So the question is, do we think if we are going to keep using panels in Drupal 8? That's probably answer will come up and we will have panels and we will start implementations. Right now I know there is a page manager that you can use. The really thing that we need and we use very heavily is panelizer. I know it's not there yet, but we will see. I mean, it's just the beginning. Yes, please. So the question is about using some Adobe product instead of designing in CSS and in browser. And ah, okay, and outputs. So this is something related to some questions to Morton. So when we get the HTML from these programs, I mean, it's maybe good in browser, but it's really not production ready thing. I mean, all the point of creating it manually, I mean, all the designing in browser, it's kind of optimization of the way CSS, JavaScript is structured and built. And if we skip this step, I mean, it doesn't matter. We will still need to rewrite because CSS files can grow big and all the point of this approach from developer perspective is to make that as nice architecture as we build the backend. So at least for now I haven't seen any solutions that were just like, wow, that's like same level of quality that our front end developer can do. So we haven't done anything with that. Yes, please. So things like menus. It's like exactly same thing like we do with views. So the question is about what we do with menus, right? When we need to override them. So we just load the menu in the backend. We have all the elements in array and then just render them in the way we like. So we don't go too much with the standard to log the trenders menu. We just create our custom pane and render menu in the way we like. Any other questions? Thank you very much. It has been great pleasure here. So if there are any more questions, you're free to come up and talk to us now. We'll stay here for a while. Otherwise you can come down to our booth, 501 and ask more questions later. Thank you.