Hannah: ...from PSD to Drupal Theme with guest speaker, Emma Jane Westby, who’s the educational development coordinator at Drupalize.Me. We’re so thrilled to have Emma on the call today. She’s been teaching people how to theme for years and in her first book, Front End Drupal, it was consistently cited as the best book to learn Drupal theming. With this video series, she’s brought them up to date with Drupalize.Me and she’s going to highlight everything on this webinar. We’re really excited to have you, Emma.
Emma: All right. We should now be able to see the slides as well. Hopefully that’s something that you can see. I'm going to get started. I'm going to try and keep things onto under an hour so we can have some questions and you can get back to your day. I do tend to get excited and ramble on about side bar topics. So I’ll try and stay focused as we go through this today.
As Hannah mentioned in the introduction, thanks so much Hannah for your introduction, my name is Emma Jane Westby. If you do want to communicate with Acquia and with me on Twitter, I'm “emmajanehw.” Or you can also get in touch with me at “drupalizeme”, all one word, also of course at Acquia. Those are how to stay in touch during this presentation.
A little bit about me. There we go. As I mentioned, my name is Emma. I work for Drupalize.Me as the education development coordinator. I am a beekeeper in my spare time. Of course, being from Canada, it’s the middle of winter right now and my bees are inactive. It is something that I enjoy doing, outside of the Drupal realm. Let's see if I can make this even bigger again. There we go. Don’t lose my Skype window for communication. So we’ll put that over here. Then come back to - oh no, I lost Chrome. That’s always the challenge with these things. There we go. Are the slides back? [Laughter]
What we’re going to talk about today and that link in this slide is actually to a copy of the slides, so if you want to follow along in your web browser instead of following along in the WebEx screen, that’s the way to go ahead and do that. Today, we’re going to talk about PSD To Theme Strategy. I'm going to talk about theming by component, which I think is the most solid way of approaching the PSD to Theme problem. We’ll talk a little bit about front-end documentation and then toward the end I've got a section of useful tools with links, and if you're grabbing the slides then all of those would be linked for you.
Let's go ahead and get started on strategy part. A sort of fun quote that I'm going to kick us off with here is, “Are you new to front-end web development? Here’s a secret. No one else really knows what they’re doing either.” That’s from Nicolas Gallagher. It’s just kind of a check for yourself to say, “This stuff seems confusing or frustrating or in any way overwhelming, it’s okay." Because quite frankly, this industry, in terms of front-end development, is moving so quickly and it’s kind of complicated for everyone who’s involved. This strategy is one that I'm been working on for a number of years, but it doesn’t mean that it’s the only way to approach the problem. There’s going to be lots of other ways of doing this. This is one that I found works for me and for the students who’ve been learning theming from me over the years.
It basically looks like this. We’re going to go from PSD to Theme step-by-step. By doing that, we’re going to focus on the individual components. The first thing we need to do is we need to identify the design components. Then create a library of basic styles according to SMACSS convention; adjust Drupal class names to match style component names; then finally, look for bugs and refactor component styles to match the design. I said the word SMACSS there, that’s one specific way of structuring your style guide. I’ll talk more about the actual implementation details and what SMACSS means towards the very end. I don’t want us to get overwhelmed or bogged down with some technical jargons that it just kind of doesn’t matter. We can look at the essence of what SMACSS is and get huge value from it.
For the essence, what we’re going to do is focus on three questions to identify our design component. We’re going to ask ourselves: What’s the shape of our design? What’s consistent? And what can be moved around like furniture? Now, let's take a lot at how this actually played out using a very simple design. This is a design that I've been using for years with my students. It was originally designed by Betty Biesenthal, who’s a Canadian designer in the Ottawa region, and it’s been modified by students to be any number of different designs. The thing I like about it is that it’s very simple and yet has a number of Drupal elements in it for us to play around with.
So, going through our three questions. The first one that we’re going to focus on is “What’s the shape?” These are essentially your layout tools for SMACSS conventions. What does that mean? The first thing that we need to do is we need to identify the grid. It’s really important when you're doing the design to theme process that you talk to your designer and ask them ahead of time to select the grid framework that they’re going to use to design the webpage design. Knowing ahead of time what the grid framework is is going to very quickly snap elements together later on. What I've got here is a design that was originally created with a 960-grid framework. Now, this isn’t necessarily the best starting point for you today, but at that time this was absolutely appropriate and the one that we decided on together. It means that when we actually snap things in place, I can very quickly use the class names that the designer had in mind when she created the design. Number one, identify the grid.
Number two, identify the containers. We went from 12 grid columns down to a three-column layout. Working from left to right, we can see you’ve got essentially a navigation column, a feature column where stuff is highlighted and then over on the right hand side we have our content column. Once those containers are in place, what I’d like to do is essentially abstract the design to a wire frame where you may have started with wire frames, this is taking you back to that abstract concept. The reason why I want to do that I is I want to be able to use text words to describe our design. I want you to, as you're thinking about your design, write down the layout rules that you would want to apply to your design.
This is essentially the shape of your website, including the number of grid columns for each of those containers that you identified. For example, the banner area with a large image and it was 12 grid columns wide. The navigation area, the left column has two grid columns, the featured area with four grid columns, et cetera. Using text at this point seems a little bit weird because we’re working with a design but as we’ll see in the next section, this allows you to really easily convert your design into code, if you start using words at this point. That’s the first one, our layout rules.
The next one is “What’s consistent?” These are typically your base or global rules when we’re talking about these SMACSS conventions. What do I mean by “What’s consistent?” I mean the things that are essentially represented by HTML element elements within our design. For example; the headings, the paragraphs, the links, what’s going to be the same from page to page regardless of where it is in your design? Of course, using again our words, I'm going to get you to write down your base rules as part of this process. For example, what are the colors that have been applied throughout the site? We had most of the text was dark gray. Our headings were a lighter gray. We have two different accent colors. Some were green, some were brown. What were all of the things that were the same, but instead of using a picture use some words to describe it.
Finally the third part, “What can be moved around like furniture?” These are going to be our components. In the SMACSS convention, Jonathan refers to them as modules, which for Drupal purposes has some pretty obvious meaning convention clashes. So we call them components instead. Now, think about furniture. It’s anything that you can pick up, move around and put in a different location. The tool that I like to use for this is stitch. Basically, a screen capture. Anything that I can draw a box around in my design is a really great candidate for a component. So if we pause at this point and take a look at out screen, we can see that we’ve got how many - and just in the chat window - how many navigation components does it look like I have? I'm going to try and find the chat window, hopefully, as you write in your answers. I may not be able to find it because I'm doing full screen. [Pause] There’s my chat window. Okay.
Let me make this bigger again for you without going full screen. Great. Okay. I see your answers coming in here. You're absolutely right. Two or three navigation components, potentially, based on the way that I've caught up this design. It’s difficult to know, isn’t it, because our furniture linens and dishes are those navigation. We have no idea. So it’s really important as you're developing these components to have very clear conversation, or communication channels rather, between your designer and your front-end developer, because the information is not necessarily captured in the design alone.
Now down on the bottom right hand side, I've got a pink box around portfolio. That’s another one that we’ve got a component there, but it’s supposed to be two things or is it supposed to be one thing? I would say that the furniture is anything that is at its smallest unit. For example, portfolio looks like trends. Those are replicating one another so the component would actually be only one of those and how they get displayed in context could be another component. We want to make this stuff as reusable as possible. So, again, following along with our rules. First we identify things and then we need to write them down. These kind of get difficult to capture in words at some point. For example here, I've got that plate with the furniture linens, dishes and we don’t really know if that’s going to be a set of links or if it’s just a picture of words. Writing down the components and handing them back to your designer allows you to have that conversation to say, “Is this what the design means? Is this how I should be building this out?” In a way that you wouldn’t necessarily have a conversation if you were relying on pictures alone.
Now that we’ve got our three areas defined; our base rules, our layout rules and our component rules, the next thing that we need to do is actually document those rules. I use plain text or mark down to create the style guide or not really a style guide but a text description of the design. This is a really difficult one for me because text seems so inelegant. In the chat window, can you go ahead and write down what are some of the other ways that you have used to describe how the design works to your front-end development team from the design team. So what are some of the tools that you use to make that communication more efficient? I really like plain text, but I know that it’s awkward to work with. On the little sent-to box, if you go ahead and click that you can send your message to all attendees and then everyone can see what the other people in the webinar are using.
We’ll let those answers scroll past. Again, the question was, “How do you currently communicate the design decisions to your front end development team?” I said that I really like plain text, and I’ll show you why on the very next slide. I know that this is a little bit unconventional. The permission may be turned off for all attendees and I may have it because I'm a panelist. I’ll get Hannah to double check that one. All right. I have the answers come flowing in.
Let's take a look at why I love working in plain text. Here is the reason. By working in plain text, I can very easily convert that information to code. In other words, by using words to describe your design files, you can easily convert the text representation of the design into code. I sort of used my air quotes on that one. SASS and CSS. Using the SMACSS convention. Our shape definitions become lay out rules. Our what’s consistent definitions become the base rules and the furniture become the component rules. SMACSS has all kinds of ways of storing the SASS files, storing the CSS, that will directly relate to these plain text styles that you’ve been writing up until it makes that conversion really easily. That ultimately is the essence of why it’s so hard to go from PSD to Theme because you're going from picture to code. Plain text I found to be a great intermediate.
Let's take a look at how this actually looks when we’re working within our SASS files. Quickly in the chat window, can you let me know, have you ever worked with SASS before? So just a quick yes or no. Hopefully, you’ll be able to convert by the end of this webinar. [Laughter] I think for mostly people who haven’t - oh! This is so exciting as I get to convert all these new people. Yay! [Laughter] Okay.
The reason I love working with SAS is that - you know how CSS based layouts are really frustrating and difficult and impossible to be semantic, right? Take a look at this code snippet that I've given you. We have here - what’s that, maybe a dozen lines of SASS and what I have done. Now the green bit should look familiar. Those are your ID selectors in CSS. What I've done is used a little bit of fancy magic in terms of the SASS fancy magic as well as a plug-in, shall we call it, for the 960-grid framework. All I do is I say when nav is used, I want you to use all the fancy magic to make it two-grid columns wide. That’s it. That’s all I have to do. So my layout SASS file is basically only this. If you follow the link from the slides - and I’ll have to link again at the very end of the presentation - if you follow the link to those slides, you can get to the repo to see this finished theme of how all this stuff fits together. It’s super simple, right? Where we had our text based description of how the layout worked, we had like - bare-12. All we need to do in our layout file for SASS is to say, @include grid : and everything else it taken care of for us - so much better than the old way of doing things.
All right. So that’s the layout. That’s the easy one. Next we go into base. The awesome thing about SASS in this case is that I have variables accessible to me. Thank goodness. Trying to remember to change all the instances of #336677 or whatever your colors are is a complete pain in the butt, isn’t it? So with SASS, what I can do is set up my variables and them simply reference my variables throughout my SASS files and get consistent colors all the way through.
Finally, we had our components and this is where things get verbose, shall we say, because there’s going to be a lot of components in any of the particular designs that you're working with. The component should be reusable. This is going to take a fair amount of refactoring as you start working with your design and building at your Drupal site to make sure; have I got the right unit of design in my description so that I can reuse some of those components? In other words, .news/teaser, that class name, can I use it in as many - very similar to less, Laurie. Absolutely. Yes. Can I use it in as many places as possible? Is it the most reusable style that I can have for this particular component throughout my site? It takes some playing to make sure that you’ve got the right amount of detail. That’s kind of the tricky part is that components sort of balloon out. On a complicated site, you may have 100 different components that you're working with. All right. Now, that’s all the style stuff. That’s the description of what we’re doing, but we haven’t touched Drupal yet.
Let's take a look at how this actually gets applied to Drupal. The very first thing that we need to do is we need to build our Drupal site. With your components in mind, you can actually take all of those stuff files that you’ve got and start building things in Drupal. Now, the reason to start on the design side is that you need those descriptions in place to figure out what to build, but the Catch 22 here is you can’t actually apply the styles if you don’t have things being rendered on a page. So there’s this horrible kind of seesaw or back and forth where you need to have both things existing before you can move forward. Which one do you do first? Some people love to build out their Drupal site entirely and then come back to their theme. Some people love to stub out - stub out is kind of a short way of saying, “Create what you think is going to be the right thing and then fill it in later.”
Although optional to work this way, I think you’ll find that using the tools that I've outlined - again, I’ll have all the links at the end - using the tools that I've outlined to build this up means that a lot of these decisions are already made for you. My kind of protest, my hesitation on this one, although I don’t use a base theme when I'm giving the example of how this theme is built. Which again, you can download at the end. I don’t use it base theme because I'm trying to simplify the process of design to theme. If you have specific requirements; for example you want HTML 5 not XHTML - is it 1.0? I can remember what Drupal core is for Drupal 7. If you want HTML 5, use a base theme. Goodness gracious, don’t do that by hand. If you want a grid framework, it could be that something like - grids or Omega or Fusion. There are lots of base themes that will provide you with a grid framework out of the box. Use a base theme. If you need accessibility compliance, I wouldn’t try and do that stuff by hand if I'm also doing some heavy theming. I’ll rely on a base theme to take care of that for me and also the responsive people. So although I don’t use a base theme in the sample theme, it’s because I'm trying to focus on something else. People are saying all kind of different favorite grids and we’re actually working with Susie on the Drupalize.Me site. So that’s another one to throw into that mix.
Okay. We’ve built our site in Drupal. We’ve got our theme kind of sketched out and now, the next thing that we need to do is we need to adjust to the template file page.tpl.php and apply the layout classes from your style guide. Now, in this case we can also insert some hard coded images, for example, the banner. This is a fraction of the page. You can see over on the right hand side, it’s there and all the rest of it. There are two things to note in here. One is that this is not semantic. Now this was the old way of doing things and the disadvantage of not using SASS is that I had to use the class names provided by the 960-grid framework. So grid-12, grid-4, grid-6. There is this Omega thing and an Alpha thing. It makes it more abstract. It makes it more difficult to understand. But when you download the new version of the theme, you’ll see that all of that stuff is semantic - so much better to work with. Okay.
We adjust page.tpl.php to match the class names that we’ve given our theme. We’ve got all these things ready to go. The next step is to finally launch a minimum viable theme. We haven't really figured out anything for sure-for sure, but chuck it onto your site and see how does it look. Did the layout work? Did things happen correctly? Are things broken? Is my layout happening in the right way? Once you’ve got that minimum viable theme, now it becomes much easier to do the dance between the design, with the theme files and the actual Drupal site. It’s easier to go back and forth once you’ve got something as a starting point.
Finally, we’re going to apply the remaining styles. Now, there are two kinds of style on this one. The easy way to apply a style is to alter the SASS files with extend so that you're not renaming any of Drupal’s weird class names. You're basically saying my semantically correct class name is the equivalent to Drupal’s weird class name. This is kind of - it’s not exactly the purest way of doing things, is it? The purest way to do something is to use template.php and actually insert your class names so that your class names appear on the rendered page. I have to admit taking the high road takes a lot more work. You’ll need to decide for your particular project, is this something where the mark up and the semantics really matter? In that case, go with the high road. If it doesn’t really matter and you just some cheap and easy wins, just use SASS’s extend and get your CSS output using Drupal’s weird class names. But the original sort of definitions and use yours semantically awesome class names.
Then as you go through each of those pieces of your site, each of those components, you can look at them as those individual little screen shots. Those little blown out boxes and you can refactor the things that aren’t working. Remove the styles or fix things that aren’t working. Don’t forget to clear cache as you're fixing things. Then repeat. It becomes easier to target each of those individual components if from the very beginning you’ve thought about how your design is structured as very separate and unique pieces. Then you see them in the Drupal site and pull them back in together. You can isolate out those elements. I find that a lot of where people who are learning to theme get overwhelmed is that it’s all one big page. If one thing’s broken, the whole thing’s broken. So how do you separate out each of those different elements or each of those different components? Do it right from the design phase and it’ll make it a lot easier to fix things at the Drupal level.
Now let's get into the guts of the tools that I've been talking about. I'm going to go through basically four different kinds of tools. Again, if you want to be able to follow the links, go ahead at lb.cm/psdtotheme-acquia has a link to the slides. You can check them all out. If you are on the HTML of the slides already, quickly hitting escape on your keyboard will zoom you out and make it much easier to navigate between the slides. I'm using reveal.js for this one.
Let's take a look at these tools. For our style guide. There’s not really a tool here but what I've done is I've described my components as text images and code. My pro tip on this one is make sure you weed your style guide daily. Do not let that style guide get out of date as you're building your theme. By using plain text, we can put the information as close as possible to the code and also very easily store it next to your code. For the Drupalize.Me team, we actually have our text based style guide inside the project repository with all our Drupal files. It becomes really easy in terms of location to keep the information up to date.
Hannah mentioned at the very beginning of the webinar that there’s a video series that goes along with this sort of quick overview and that’s the link to this specific video within that - I think there are 21 lessons altogether. That’s the link that goes to the specific lesson. You’ll need to be a Drupalize.Me member to view that particular video or an Acquia Enterprise participant. That gets you a seat in Drupalize.Me. I'm sure Hannah will be able to help you out with those of you who’ve got Acquia subscriptions but aren’t quite sure how to access that. So it’s number one. Style guide.
Let's go onto the next part. SASS and Compass. My tips here are to ensure your styles are modular and that your CSS is reusable. Use a relevant startup kit for your particular project. Now in my case, I was using the 960-grid framework plug-in, which I found in GitHub, which had a little starter script for me. Your starter kit does not need to be a Drupal base theme. If you are completely new to SASS and Compass, we’ve got an entire learning series on SASS and Compass.
The next one, the grid frameworks. Choose a grid framework during the design phase and either use the extend directive in SASS to make your good framework semantic or as I mentioned before you can use the high road or the hard way. [Laughter] What the template .php edits. We've got a video lesson for this one as well. The next one here, these three are all links. You’ll definitely want to go ahead and grab the slides to follow those links. These are the resources on applying SMACSS to Drupal. Now, the thing that I haven’t really told you up to this point but I think you’ll be kind of excited about in Drupal 8? In Drupal 8, the CSS coding standards that we used are based on the SMACSS principles. I'm just going to put into the chat window here. I took out the slides that talked a bit more about SMACSS; Scalable Modular something CSS. Can someone follow that link and type in what the SMACSS stands for, please, because I also get it wrong.
The Drupal 8 conventions are specifically using SMACSS. You don’t need to wait for Drupal 8, though. These are lessons that you can start applying in Drupal 7. Paul was mentioning that the Zen starter theme is also based on the SMACSS conventions. There are other conventions as well. There’s - as the name in convention. If you were a front-end developer, please go ahead and put in to the chat window what some of these other conventions are. Those links there are some of the resources that you can use. But dominate the theme layer is a video that of that method whose last name I will butcher so I won’t try and pronounce it. He's in Munich? If you want the high road or the hard way of getting those class names into Drupal. He gets some really great tips on how to go ahead and do that for the advanced front-end developers in the group.
Those are the resources. Now, let's go through quickly the summary. “Theming by component makes stronger connections from your static design files to Drupal much easier.” “Incorporating the right tools early in the process makes it easier to snap pieces together later.” Think back to that slide where I only had about 12 lines of SASS and that was going to snap together my entire layout for the site. Then finally, “Theming can’t exist without a Drupal site." You can’t theme something which doesn’t exist. You can create styles but you can’t truly apply those styles without the underlying markup and that dance between Drupal and the design files is what makes theming so exciting, I think, for front-end developers. Do I want to change Drupal? Do I want to change my SASS or my CSS files? At what point do I make decisions for one or the other?
Here’s the link again to those slides. I think there are half a dozen or more slides at the end. Just some extra resources in terms - I'm just going to hit - here we go. There are some extra diagrams here, a couple of extra links if you go and take a look at that deck.
I think we have maybe about 20 minutes for questions. This is the end of my formal presentation, though. If you're short on time, click the link. Make sure you got those resources but that’s all I've got for you in terms of a structured presentation. I would love to be able to - I will put into the chat window. Yes. You could copy and paste. lb.cm/psdtotheme-acquia, there we go. That should be clickable. Let me try that again. If you start putting in your questions - there we go.
Hannah: Awesome. Thank you so much, Emma. If you have any questions. Could you please ask them in the Q&A section? We had a first question come in. “I love the idea of variables in CSF. How much time can I expect to begin using SASS and Drupal as a novice themer who has never used it before?”
Emma: I found it really easy to pick up, in part because it was a tool that I had been wanting for so long. Now, there are more complicated ways and less complicated ways of doing SASS. The concept of a variable, just in terms of assigning colors, is super easy to do. So that part of it doesn’t need to be complicated. If you just look for general resources on SASS, and Compass gives you some extra preset shorthand things that you can take advantage of. You don’t need to use Compass in order to use SASS is what I'm trying to say. There is a lot of resources on the internet, but just using variables and just using SASS I would say that’s something that could figure out within a day.
Hannah: The next question is, “How do you handle responsive elements from PSD to Drupal?”
Emma: We could do a whole video lesson on this, couldn’t we? Or a whole webinar. It’s a really tricky question. I think that one of the ways to approach it is to start thinking in components that have the context of a page or a larger viewport. When you're thinking about an individual component, how does that component behave at large or small screen sizes? I get really frustrated when people say, “Oh, a designer shouldn’t be using Photoshop anymore.” That’s crazy. That’s your creativity tool. You should be able to use whatever you want as a designer in order to think creatively about a problem. That doesn’t mean that it’s the best delivery tool for the front-end team.
If you have the HTML slide pulled up, remember that picture that I had where I had boxes on top of the gray box of the different components? If you can get your design team and your stakeholders to start thinking about components instead of just pages, I think it becomes easier to design responsive sites. Because you're thinking about how does that component exist within the context of the viewport. Hopefully that answers your question although it is, like I said, it could be an entire life [laughter] worth of trying to figure it out. It is a tricky problem.
Hannah: The next question is, “I have Drupal commerce site that I’d like to convert SASS Compass in the next re-design. How do I convert an existing theme to these frameworks?”
Emma: Really interesting question. There are a few different things to think about. One is what are you trying to get from the grid framework or from SASS? Then the next step is to figure out - are you just sorting CSS into different files in terms of their components. Are you adding in a good framework? SASS itself doesn’t give you much. It gives you the ability to do variables. It gives you the ability to do components. SMACSS gives you the idea of conventions in terms of the base and the layout and the component rules. So there are lots of different pieces. You don’t need anything in order to do that rewrite into SASS. It’s more how are you going to use SASS to take advantage of things? Are you going to be adding in a grid framework. If you’ve already got a good framework and you want to rewrite things in a more SASS-ish way, is there a conventional or is there a plug-in that’s set up which can give you some pointers on that? What can the tool do, but also what do you need it to do?
Hannah: The next question is, “So using a base theme to start and then create your own theme using SMACSS and add extend base theme class is a legitimate Drupal theming process?
Emma: If you can make Drupal look the way you want, I would say that it is a legitimate theme. It may not be a best practice, but best practices are constantly changing. Three years ago, I taught people to make really specific CSS selectors that targeted very tiny bits of HTML fragments of various specific used cases. That might have been like; include a note ID as part of your CSS selector. I would never advocate that today. Yet, it’s only because of SASS coming in that I can say, “Be more semantic in your markup.” It doesn’t add a huge cognitive overload when you're just learning it. It doesn’t add a huge amount of time, necessarily, because we didn’t have a new tool. There’s a lot of different things that I've introduced here today if you're completely new to front-end development, but pick the pieces that work for you. Certainly, I encourage you to learn these new things but also, if it’s not working and you just find yourself banging your head against the wall, just make it work for you. [Laughter] Don’t let the tool get in the way. What’s the expression that Jeff Robins uses? “Done is beautiful.”
Hannah: We had some more questions come in. This person was just wondering if they missed this but wondered, “If Photoshop isn’t the best tool for design to front-end, then what is?”
Emma: That’s not what I meant to say at all. What I meant to say is that designers should be able to think creatively in any tool that they find useful. Many designers are trained in Photoshop and they find that Photoshop is the best tool for them to be able to think creatively. I do not advocate against designers not using Photoshop. I think designers should be able to use whatever tool they want. However, when you are working with Photoshop you are confined to the idea of a page so the way that you combine the components within Photoshop can be difficult to create the variations for responsive web design.
As you're doing a design delivery, don’t simply think of delivering a single page as a designer, but perhaps think about delivering components which have been designed in Photoshop. Photoshop as a great tool for idea of creation, but the static PSD file is not the way that the web behaves. Use it to think creatively, but - it would be crazy if you did a Photoshop file times every single different combination of factors that existed on the web today. Designers, you don’t have time to do that. There would be so many variations that you would have to hand off. Instead of thinking about designing pages in Photoshop, think about designing components and what’s the context that it’s going to fit in, what are the relationships between like a full screen desktop layout versus a handheld? How does that component behave in those different places?
It’s not right or wrong to use Photoshop. It’s just what’s the handover piece. In some cases, it’s going to be a Photoshop document. What is in that? Is it a component? Is it a fraction of a page? Is it a whole page? Is it here are 50 different components and three wire frames that they fit into? How does that work? I see someone in the comments saying, “I use pencil and paper for design." Absolutely. Designers should be allowed to use, whatever tool they feel most comfortable in for the idea of creation process. I’ll get off my soapbox now. Go ahead. [Laughter]
Hannah: Thank you for clarifying. The next question is, “Do you use PSD slices, name your slices in export or is that overkill? Or is it just situational based on the design?”
Emma: Definitely situational based. My dirty little secret is that I do very little work in Photoshop. I mostly use GIMP, which is an open source equivalent to Photoshop. There’s a lot of built-in things for Photoshop in terms of layer effects or effects just generally which don’t translate well into GIMP. So I generally - when I'm working with a designer, I have them export exactly the assets that I want to insert into my design. Whatever process works for your team is the right process to be using. Just I have a conversation with your frontend developers. Do they want slices? Do they want things made in Photoshop? Do they want assets extracted with a pane that shows on how it all fits together in the context? Like I said, whatever works for your team is the right approach.
Hannah: The next question is, “What framework should I be choosing from the beginning of a project?”
Emma: That’s a really difficult question, because I don’t know what you're support network uses. I always advocate going for - when you first start, what are your friends using? The reason why is that you can get free help from your friends, hopefully, if they’re friendly. [Laughter] But seriously, ask around, see what people are using and see who’s got the best approach in terms of answering your questions that fits with you and start there. It doesn’t mean you’ll stay there, but start with your support network.
Hannah: The next question is, “Is it safe to build your grid based on wire frames?”
Emma: I don’t think I understand that question yet. Is it safe to build - I think the question is saying, “Do I need to get to a completed design or can I just build my rough Drupal theme starting from the original wire frame standpoint?” If that’s the question, my answer is yes, but you may not want to show it to the stakeholders. You can start thinking early but you wouldn’t necessarily want to get client sign off. Some clients can’t picture things the way you and I can picture them. So it depends on your client. If I've heard that question correctly.
Hannah: Yes. I think that answers it. The next question is, “Is there a good responsive base theme that let’s a site builder do most of the design through UI instead of writing files?”
Emma: If you want a pointy-clicky base theme, I would recommend for Drupal 7, not for Drupal 6 and not for Drupal 8, looking at Omegas 3 or Fusion for base themes. That said, I gave a presentation in Munich on how to evaluate base themes. I can’t remember the name of the presentation or the link off the top of my head, but if you search for my name - I will find the link and post it in this chat window. [Laughter]
Hannah: [Crosstalk] Great.
Emma: Not that these are complicated it was my maiden name instead of my married name.
Hannah: The next question is, “As someone who hasn’t implemented SASS yet, can a PSD be easily converted using SASS or Compass?”
Emma: As long as you go through the steps that I have outlined in this process, which is to go PSD text description and then work on your SASS files, I think it’s relatively easy. If you don’t go through that text description of the design first, then it’s very difficult, I think.
Hannah: The next question is, “To come back to the base theme, what makes you decide to use a base theme or build your own theme from scratch?”
Emma: Well, it depends what you're trying to accomplish. For example, let's say I have a project where I know that I want it to be HTML 5. I can either go through and rewrite all the Drupal core - again focusing on Drupal 7 - I can go through and rewrite all he Drupal cores default template just in case one of them gets used accidentally. I can write all of my own template files for only my specific instance, or I can just grab a base them that’s already done all about work for me.
Base theme are essentially starting points. A base theme is only a good fit for you if it uses the same starting point or the same advantages as what you need for your particular theme. In terms of what should I use one? Should I not use one? How do I make that decision? What are the requirements of the markup and what does the base theme provide you with? Then, it’s an amazing base theme to teach you how to theme. It is incredibly well documented. But if you want a pointy-clicky layout tool, it’s not the right base theme. What you want is Omega 3, not 4 but 3. Again, it depends what your requirements are to be able to decide if the base theme is right for your particular project.
Hannah: The next question is, “We use Bootstrap and LESS in our last project, I just read in a chat that similar to SASS and Foundation. What would you recommend? What are your thoughts on that?”
Emma: That’s like saying what’s better, Joomla or WordPress. I don't know what’s best for your particular project. They’re similar. They both have followings. They’re both popular and if LESS and - sorry, did you say Foundation? If LESS is meeting your needs, stick with LESS. That’s fine. You don’t need to switch to SASS. SASS has, I think, more energy behind it moving forward. I think it has therefore more resources, more help available online. Ultimately, depending on who you ask, too, perhaps some more sophisticated concepts or capacity than what LESS offers. But if LESS can do everything that you need today, it is adding a bit of overhead to go and learn something new just to learn it. It’s cool if you have time, but if LESS is meeting your needs, that’s fine.
Hannah: The next is, “Have you use brackets to ID which converts Photoshop images to HTML tags auto-magically?
Emma: I don’t trust auto-magic things when it comes to images. I'm pretty old school. [Laughter]
Hannah: The last question is, “What are the general hurdles to expect when working with responsive theming?”
Emma: The general hurdle would be no matter how many devices you’ve tested it in, your stakeholder is going to have a device that you didn’t know about and they’re going to want it to look perfect in that device as well. I think that’s the biggest hurdle that you're going to have to deal with.
Hannah: Great. Thank you. I think that’s it for questions. If we missed them, I apologize. Again, thank you everyone for attending and a big thank you to Emma for presenting to us today. Really excited that she was able to be on the call. Emma, would you like to end with anything?
Emma: I just want to say a huge thank you to all of the folks who are still in the recording. It’s hard to watch in webinars. It’s a lot of staring at the screen and trying to stay engaged. Thanks so much for everyone who participated in the chat window and hang out with us for an hour. I had a lot of fun. I hope you did as well. Thanks, Hannah, for hosting, too.
Hannah: Of course, we’ll be sure to send the recording and the slides out in e-mail as well, so you should be seeing that tomorrow. Thanks, everyone. Have a great day.