Feb 21 2013
Feb 21

Going from static design files to a completed Drupal theme can be a daunting task. I often get asked "strategic" questions by companies who are looking to hire a designer/themer for an upcoming redesign and aren't quite sure what skills they should be looking for. And I often get asked by new-to-Drupal designers how they should approach the task of transforming their design into a Drupal theme. In these conversations the following question (almost) always comes up:

Should I create a static HTML page of my design and convert that into a Drupal theme?

Can you guess what my answer is?

Five years ago, when I was first writing Front End Drupal, the answer would have been "Yes!" Five years ago there were fewer moving parts to creating a Drupal theme. There were fewer contributed modules. Responsive design wasn't even an idea yet. Five years ago I don't think that "mobile" was even a thought for most businesses, let alone a concern.

But today, in 2013, my answer has definitely changed. Now when asked if people should create a static HTML page of their design before converting it into a Drupal theme, my answer is "No!" In fact, depending on your budget size for the entire build and the type of site you're building, you may actually want to skip "static" design files for each layout (and layout variant if you're building a responsive site) and have your designer supplement their work by creating "style tiles" instead of piles and piles of page-specific layouts.

Designing for a style, instead of a specific layout, is a different workflow though. You'll need to have a relatively experienced content strategist, designer *and* themer to help you navigate this workflow for theming Drupal. Pixel precise designers are much easier to find. But here's the problem with pixel perfect design: it relies on exact markup. Drupal is markup-heavy and can drive a themer crazy if every single tag, and every single class must be exactly perfect. These days, it's easier to skip the "static" step and get into Drupal as fast as possible. Sure, you'll still want to refactor some markup (or maybe just start with a different base theme), but the point is that you aren't starting from thin air.

Themers who want markup purity tend to be coming at their work from an Model-View-Controller (MVC) perspective...which isn't what Drupal does. We're a Presentation-abstraction-control (PAC) framework. The main difference between the two (in laymen's terms) is the fragmentation of the output/markup files. Our system has lots of little nested template fragements which are compiled, or collected, into a whole. This means if you want very, very precise markup, you have to alter a lot of little files. Some of us love it because you can get really fine grained control in very tiny places without having to touch all of the markup, others hate it for exactly the same reason.

Regardless of which camp you're in, there doesn't seem to be a lot of information about building themes that talk about these software design patterns. A quick search reveals the following tutorials and articles (most are quite old). If you've got others you'd like to add to the pile, please leave them in the comments. Things get very technical very quickly...but hey, this is a list of links about software design patterns. It's supposed to be technical.

Feb 09 2013
Feb 09

Yesterday I made a very bad assumption that's wasted a day of my time. Today, while I wait to hear back on where I went wrong, I thought I'd write up a little warning to my future self.

First, a bit of background: It's very unusual for me to start a project at the beginning. Most of the time when I'm working on a project it's doing little fix-its for a client as part of a larger training contract. Sometimes it's simplifying things to eliminate the need to train users on complex tasks; sometimes it's tweaking a theme to accommodate the way content is being placed into the site now that it's a Real Live Web Site. Regardless of what I'm doing, I seem to spend a lot of time fitting into someone else's work flow. I'm used to it, and usually I enjoy the discovery process.

Yesterday when I hopped onto a project, I was thinking about checklist of jobs (images in the sidebar needed to float: left, lightbox module needed to be installed for a gallery, verify backups are working properly)...but I wasn't thinking about the fact that this project had already had multiple rounds of developers working on it...potentially each set having their own preferred workflow. In retrospect, this is what I *should* have done right from the beginning (and all at once) instead of only doing little bits and pieces over the course of the day while pausing to bang my head against a wall.

Conditions:

  • The project has had more than one developer/development team working on the project before you start.
  • You only have FTP access to the server (yes, seriously).
  • The only way for you to pick up the files you need to be working on is by downloading them via FTP from the live server to your work station.

How I *should have* started this project:

  1. Look in the theme folder for documentation about how the theme was built. If there is none but there are preprocessor files (LESS or SASS), stop immediately, and ask to speak with the previous developers. (I assumed I could just muscle through it without docs...because I'm psychic and code is self-documenting. HINT: turns out this actually just means that I'm psychotic, because CSS preprocessors are totally NOT self-documenting....so you can probably tell that I skipped this step?)
  2. Download as many relevant files as necessary to run the site locally (in this case it was the entire site + a B&M snapshot of the database).
  3. Put everything into version control. Do not pass go. Do not make changes until everything is in version control. (Did this. /me pats self on the back.)
  4. (This is where I went wrong.) Create a new branch and recompile the CSS files from the source preprocessor files (e.g. SASS or LESS).
  5. Assuming you're using Git for your version control, run the command:
    $ git difftool mynewbranch..master
    Look for differences between the two branches.
  6. If there are any differences in Step 5, stop immediately. There is a problem. Either you are missing the source files (i.e. .scss or .less), OR someone has been editing the CSS files directly. Stop and find out which problem you're dealing with.

Possible scenario #1: If you're missing source files: easy! Once you've got the right files you can continue to take advantage of all the awesomeness you get with a CSS preprocessor. Of course once you get the source files, you should repeat steps 4-6 until you can get your output to match what's on the server.

Possible scenario #2: If one of the developers along the way has been editing the CSS files directly: easy! Delete all of the source files from the preprocessor and do your work like it was 1999. Well. Except with more awesome version control than what was possible back then. Of course if you love to punish yourself, you can carefully inspect the live CSS files and pull out the hand-edits and put them back into the preprocessor files where they belong. Chances are very good that your client won't want to pay for this step. Only you can decide if it's worth eating the time costs.

So there we have it: a note to my future self about making assumptions and jumping into the middle of a problem. Do you have your own process for dealing with inherited projects? I'd love to hear any tips you'd like to share.

PS @rupl over at Four Kitchens helps to solve this problem by including a WARNING file in his SASS source files. You can read it here. I think it's brilliant. and so does fubhy.

Feb 04 2013
Feb 04

On the back of an envelope, tucked into one of my office drawers, is something that comes very close to being my personal mission statement: your problem is already solved--you just haven't found the answer yet. You see I'm not much of an inventor. I'm a connector. I take stories out of context and apply them to new situations. I look for patterns and love helping others to make their own connections to make their own work flow better. My talk on base themes in Munich is a perfect example of the kind of work that comes naturally to me: sorting, examining, classifying, naming, and sharing the results with others.
 
It's probably because of my love of patterns that I rarely start a project from the very beginning. If it's possible: I like to find the middle of the problem and then work out.
 
Theming, by it's very nature, will always put you into the middle of the problem first. When you're lucky you're given static design files and a site full of content and your job, as a themer, is to start in the middle and work out until the design has been reincarnated as a fluid, interactive, adaptable colony of content. But where is the middle? Sometimes you can intuit where to begin. (Although it's probably because you used to know and simply forgot.) Leaving things up to intuition seems a bit risky though. Especially when, as I personally believe, the answer is already waiting for you.
 
When I start a new theme, I ask myself: "What is here that I have seen before?"
 
I look for patterns.
 
I don't mean background textures...I mean the shape of the content inside the design. You can do this too: you can teach yourself to look for patterns, and then use existing solutions to quickly solve your problems.
 
Here are a few of the bookmarks I've collected over the years on pattern used by front end developers. I hope you'll find them as useful in solving your own theming problems.
 
Let's start with a bit of inspiration:

  • User Interface Design Patterns. A community-generated collection of web site elements (aka design patterns). Includes a problem summary, example, and usage guidelines for each pattern.
  • Elements of Design. This one isn't so much a pattern library as an inspiration gallery. the elements are linked back to their site of origin so that you can see them in context, however, sites are often redesigned and it isn't always possible to see how the element fit into the bigger site design.
  • Yahoo! Design Pattern Library. A tightly curated gallery of patterns that Yahoo! uses across its sites. You'll recognize examples from Flickr, Yahoo! Mail, and Delicious (bookmarking).

Now let's get more technical:

  • Pears. Common patterns of markup and style. Don't be put off by the CMS. Look through the pages and you'll start to recognize the types of elements you probably need to build on your site too (e.g. Slats (thumbnails) could easily be a view with a resized image field). Your base theme may also give you a bunch of HTML selectors to help you target patterns (e.g. Fusion and Zen).
  • Modular CSS helps you "see" the patterns in a design file and convert the patterns into CSS.
  • Jesper's talk from DrupalCon Munich, Dominate The Theme Layer, expands on the ideas in Modular CSS, and applies them to the Drupal context. (note: I don't think Jesper's presentation is based on the other article, but as a reader I think you'll find they flow together nicely.)

So go ahead and jump right in with your theme. But don't think for a second that your design is a special snowflake that is nothing like anything ever built on the Web before now. Do the research: look for patterns. And remember: your problem is already solved--you just might not have found the answer yet.

Jan 30 2013
Jan 30

Sometimes I work with clients who don't have the internal capacity to set up a developer environment for me...but they still want to be able to track what I'm working on in a semi-private space. In fact I had one such project a couple of weeks ago. My go-to service for this is WebEnabled. It's a paid service (and I don't get paid to promote their service), but you could definitely replicate the concept in other environments. I use a similar process when I'm working with the Acquia Developer Desktop on my windows machine.

This process isn't ideal for working with teams. And it's not my typical setup. But I think it helps to get people thinking about how they can use version control even on very tiny projects.

  1. Install the base environment (Drupal+LAMP stack) with the basic D7 core package from the WebEnabled app library. This gives me Drush and the basic file structure for Drupal. I won't end up using much of the basic environment, but it's an easy starting point.
  2. Use Drush to add the module Backup and Migrate. In WebEnabled this can be done through their Web-based admin tool, or on the command line (through an SSH connection).
  3. With Backup and Migrate, create hourly schedule with 3 days of keeping backups. (Test the backups!)
  4. Add version control through the WebEnabled interface (you can choose SVN or Git, I use Git).
  5. If the client has provided a snapshot of their Drupal file system, I copy the relevant folders (especially sites/all, and profiles) into my dev environment.
  6. Perform an *environment* backup of WebEnabled in case the next step fails. This is not the same as the Backup and Migrate *database* backup.
  7. Import the database snapshot from the client. Depending on how it's been provided, this might happen through phpMyAdmin (WebEnabled sets this up as part of the originial provisioning of the environment), or through Drupal if it's a Backup and Migrate snapshot.
  8. Use WebEnabled to reset the user/1 drupal password.

The development environment is now set up and ready for me to use.

For this particular project I was *only* working on a simple theme. No extra modules. Nothing fancy. So I used my git repo on WebEnabled to store all my theme folder.

In my local work environment (not WebEnabled), I completed the following steps:

  1. Clone the git repo from WebEnabled. (It's empty right now.)
  2. Add the starter kit from my base theme of choice. (Or, in this case, my client's base theme of choice.)
  3. Tidy up the starter kit to match my theme name.
  4. Add "major" images (e.g. background images, logo) to give a quick win for decorating my new theme to match the design files.
  5. (all along I've been committing my little changes locally to git) upload my new theme to the central git repository that WebEnabled provides, by using the command git push.

Next, I log into the WebEnabled dev environment via SSH, and complete the following steps:

  1. Navigate to the appropriate theme folder (e.g. sites/all/themes).
  2. Clone the WebEnabled git repository for this project as a new theme folder.
  3. Use Drush to enable the new theme.

Now the real work begins! Most of the tasks I'll do in my local developer environment. When I'm ready to share a batch of changes, I'll complete the following steps:

  1. "git push" the files to the central repository on WebEnabled.
  2. Log into the WE server and "git pull" the updated files from the central repo into the semi-private development server's theme folder.
  3. Use Drush to clear all the caches (drush cc all).

That's it!

What are your favourite tools and services for quickly sharing your work? I'm especially interested in hearing from other small teams who may not have a lot of infrastructure support.

Nov 14 2012
Nov 14

 I've been working on a new talk, to go with a new workshop, on setting up a developer's environment for very small teams. It got some great questions today at DIG London, and I'm hoping you'll enjoy hearing it at DrupalCamp Toronto as well.

Interested in the full workshop? It starts next Monday. Details about it are available here.

Sep 04 2012
Sep 04

Are you a Drupal developer? How are your PHP skills? Are you ready to upgrade your modules for Drupal 8 with new OOP design patterns? Do you know what all the changes are in PHP 5.3? Are you excited, but thinking perhaps you might need to blow into a paper bag for a while to stop freaking out about all that's going to change? Yes? Read on, my friends.

In two short weeks PHP expert Lorna Jane and Drupal expert Emma Jane (that's me!) will be offering a brand new master class for Drupal developers. This course is specifically designed for Drupal developers who will need to master PHP in order to prepare themselves for Drupal 8.

This workshop will lead you through:

  • Best practices for object oriented programming in PHP.
  • Refactoring your modules for new language features in PHP 5.3+
  • Using Symfony components in Drupal 8.

Unlike other workshops, the seats for this class are being sold per company. We encourage you to participate with your co-workers. We already have a number of skilled companies signed up for this workshop. This is a class you're going to look forward to. All the smart kids will be there, and you should be too.

How do you sign-up? It's as easy as filling out the registration form. Once you've completed the form, Emma will be in touch to coordinate payment.

We look forward to seeing you in class. It's going to be amazing!

PS for mr.baileys: yes, the goal is to GPL the curriculum so that it is available for the entire community. You can read about the funding model here.

Aug 21 2012
Aug 21

I've had a great response today from my presentation at DrupalCon Munich. If you weren't able to make it, no worries! The video is already online. I'm having some technical difficulties getting the fields published with my handout and my slide deck, so I've added links here.

I've had a few requests for the diagrams in the talk. I'm happy to supply the source files to the community (they're SVG). I don't want this blog post to be the canonical source though, so I've created a git repo with the diagrams. Please feel free to contribute, or make modifications if you've got other diagrams you've found handy in explaining theming to others.

Aug 07 2012
Aug 07

In less than a week I'll be flying out to Germany for this year's European DrupalCon.

Thursday August 9. If you're a speaker, you'll want to attend the third and final speaker check-in. It's taking place online this Thursday. Details on the speaker resources page. The session will include all the details I have about your rooms, the projectors, the microphones, the stages. You can pre-register and have a reminder email sent to you so that you don't forget. (The password is always "drupal".)

Tuesday August 21. My own DrupalCon session, Evaluating Base Themes, is a spin-off from this blog post. As part of the session I've had the creators of the base themes tell me what they thing the best, and worst, features are for their base themes. I'm really looking forward to this talk. If you can't make it to Munich, be sure to watch the recording later.

September 20. Seats are filling up for my new workshop, PHP for Developers. This workshop is for Drupal developers who want to hit the ground running for Drupal 8 with the new PHP language features, OOP, and Symfony2 framework. (It includes pre-workshop resources for junior developers too.) I am co-teaching this course with Lorna Jane. Registration is going very well and I expect we'll sell out before the end of the month. Participant sponsors in the workshop include Stanford University, Drupalize.Me, Teach for America, Ixis, and Open Sourcery. I'd love to add your company's name to this list. Read more about this workshop specially designed for Drupal developers who are ready to level up.

Jul 16 2012
Jul 16

This spring Emma Jane (that's me) and Lorna Jane were chatting about PHP training and Drupal workshops. While there are many workshops on how to teach PHP developers how to Drupal, there are no workshops teaching Drupal developers how to PHP. Things change radically again in Drupal 8 as we bring in PHP 5.3 (yay! namespacing!) and Symfony2 (read the comments on this old post to get a sense of how "excited" the Drupal community was; read the issues on d.o to see things that are being done that are Symfony-related).

So it's all very exciting, right?

But what if you're a developer and you've got a billion contrib modules (*cough*davereid*cough*eaton*cough*)? Well if you've got a billion modules, you're going to need a lot of help to review your code and see what can be updated. And if you've only got a few modules you aren't necessarily going to have been knee deep in the refactoring muck and you won't necessarily know where to start.

That's when Lorna and I hatched a plan.

Lorna Jane is a PHP expert. She's not a Drupal expert. She knows how PHP works when it's not full of Drupalisms. (She also happens to be one of the organizers of Symfony Live in London. and right now she's at OSCON giving talks on PHP language features and writing awesome APIs.) In September, Lorna and I are going to teach a workshop to help Drupal developers see their code through PHP eyes, and not just Drupal eyes. We are seriously excited about this workshop.

The workshop will cover object oriented programming, design patterns, Symfony2 and new language features as of PHP 5.3 that some Drupal-focused developers may not be aware of. It will be conducted online, with two real-time events (September 20 and September 27).

Awesome, right? This is where it gets really awesome....

Right now I'm in the process of open sourcing my flagship workshop, PSD to Theme. And I had this Oprah moment where I was like, "And you get a car! and you get a car!" and all of a sudden it occurred to me that this workshop should be open sourced too. (It took me about 11 seconds to convince Lorna Jane that this was a good idea...which is about as long as it took me to say it out loud.)

To fund the development of the workshop, we're doing it kickstarter style. Registrants know exactly what our goal is (help developers to level up for Drupal 8; and open source amazing, and relevant workshop content), and we know what our funding targets are. Instead of selling single seats to individual attendees, we're working with companies who have 5+ developers who need training and selling a single "company" seat (with "unlimited" participants per company). This allows companies to send as many developers as they think will benefit from the workshop. There are 25 company spaces available...and a few of these are already tentatively booked. (Hint: there are more than 25 Drupal shops. Hint, hint: open source means that companies offering *training* may want to be part of this as well.)

You can read more about the program at its micro-site: PHP for CMS Developers.

Feb 07 2012
Feb 07

In 2011, Acquia hosted my very popular session From PSD to Theme as a webinar. 1800 people registered. Eighteen HUNDRED people. And in one of the best response rates I've ever seen for a free webinar, over nine HUNDRED people signed on and watched the session live. An early draft of the slide deck received over twenty nine THOUSAND views on slideshare. And now? There are FOUR. 1..2..3..4.. seats left in my DrupalCon workshop, From PSD to Drupal Theme: A step-by-step approach to creating your first Drupal theme.

This workshop takes place on March 19 in Denver, Colorado and is part of the pre-con training offered by the Drupal Association at DrupalCon Denver. It will be taught by me (Emma Jane).

I am very excited to be extending this incredibly popular one-hour presentation into a full day workshop. Unlike the one-hour presentation version of this workshop where hundreds of people can attend, seating in this one-day workshop is very limited. You will get individualized support on the day of the class, and an additional 30 days of support after DrupalCon. No more feeling frustrated that your questions weren't answered. Together, we'll work through two PSD to theme conversions. You can even bring one of your own designs to the workshop!

If you can't attend, but really wish you could, check out the themes Vert and Domicile. Attendees will also get a free copy of the step-by-step workbooks and PSD files for the designs (also available here and here). These are the designs we'll be working on during the day. What you'll be missing if you can't attend is the experience of working with me one-on-one to solve your Drupal theming obstacles. In the workshop you'll also get to meet others who've been frustrated by Drupal theming (or maybe have just been too scared to even try). It will be a fun day (promise!) and you'll come away from the workshop ready to take control and make Drupal look as good as your imagination.

Got questions before you register? Get in touch. Remember though: only FOUR seats remain for the workshop on March 19. Register now and I look forward to seeing you in class!

Dec 23 2011
Dec 23

Just in time for holiday reading, I've released THREE new Drupal workbooks.

Earlier this year two of my good friends asked me to build them a web site for their band, Beckon. This workbook outlines (in great detail...over 70 pages) how I built the features you see on the site and even more features that are still in the works. I won't lie: multilingual content can be enough to make your head spin if you don't understand the basics. Fortunately a lot of programmers have spent a lot of time developing the multilingual capabilities of Drupal--so it is possible to create a multilingual Web site...if you know how. This guide walks you through the basics of content translation models and creating your own multilingual sites with Drupal. Perfect for site builders with experience creating Drupal sites, but with no experience working in multiple languages. This guide will help you to choose the right content strategy for your translated content--saving you valuable development time. Matt Haughey (MetaFilter) once said, “Forms are tedious, confusing, often poorly designed, and most people equate their use with things like paying taxes.” In this workbook, you will learn how to alter Drupal’s forms so that their purpose is obvious and they are easy to use. Most Drupal themes focus their styles and manipulations on the customization of content, not input forms. As a themer, you may have created a page template and perhaps individual node templates for each of your content types. This workbook is based on Chapter 6 from Front End Drupal. If you loved my first book, you'll love this workbook.

If you're taking time off over the next couple of weeks I hope you have a great holiday season. :)

Dec 01 2011
Dec 01

For my new workshop I had to create 200+ accounts. It was enough that I wanted to do it programmatically, but not enough that I wanted to set up Migrate. I opted to use Feeds instead. That turned into a world of pain that went something like this:

  1. When importing new users with Feeds, there is no option to trigger the email for new accounts (that I could find). This means after you've created the accounts you still need to tell the account holders that they now have accounts on your site.
  2. The token/rules integration does not allow for one-time-login links to be used for new emails the same way that the core email for new users allows you to place a token for a one-time-login link.
  3. Even if VBO integration for One Time Login wasn't broken for Drupal 7, you'd still have to know your password to change your password ... so after clicking "send one time login" on 200+ accounts BY HAND would still receive 200+ email saying, "thanks for the login info, but I can't change my password without my password, can you email me my password?" (There may have been real live tears at this point...) Although someone told me that only admin users are supposed to be required to enter their password to change their password, I can't find a bug for this and I'm okay with the extra layer of security so I won't submit a bug for it.
  4. I don't think Quick Pass Reset ever claimed to have VBO integration, but you can click-to-edit everyone's account and resend a "reset password" email by hand.

That last option will save your bacon.

Although it's all done now, I think next time I'll just put on my big girl pants and use Migrate.

PS You're welcome to torture me in the comments with "what you should have done"s. ;)

Nov 23 2011
Nov 23

There's a brief window between where I feel comfortable selling a product that's no longer totally up-to-date and that product becoming totally obsolete. Today I pulled the plug on my best-selling workbook Theming Drupal: A First Timer's Guide and have made it available as a free workbook: Theming Drupal 6. No subscriber wall. No hassles. No worries. No time limits. No interrupting turkey dinner or whatever else you're up to this week/end. That link will be there for you when you're ready.

But you know what won't last forever? Registration for my brand new workshop: Responsive Web Design for Drupal 7. Class starts December 1st (that's *next Thursday*) and it's going to be amazing. There are already over 200 people registered for this workshop. (Wow!) To make sure everyone's settled in, I am closing registration on Tuesday November 29th. I look forward to seeing you in class.

Nov 10 2011
Nov 10
Home

Shopping cart

View your shopping cart.

Join the Mailing List

We help designers make amazing themes and templates for Drupal. The mailing list has notices about upcoming classes, free tutorials and sometimes has discounts and free give-aways. If you're struggling to be a better Drupal themer, you want to be on this mailing list. Email: It’s rare in Drupal that you need to truly build a theme from scratch. It’s also rare that you should use Bartik as the base theme for your site (unless you want to — which is okay too). My three favourite base themes are NineSixty, Zen and Fusion. I like them for different reasons and each of the three themes only when it’s appropriate. Zen for its documentation, NineSixty for the speed of banging out a design as a theme, Fusion for client-controlled, future-proofed themes. Even though I have my favourites I still like to stay up-to-date with what other base themes are doing. This blog post (and the video at the very bottom) cover how I evaluate base / starter themes. Note: I evaluate for themer experience first. The quality of the markup (semantic, valid, accessible) is not my priority at this stage because I'm usually adding my own markup to the mix as well. When you evaluate your base themes it may, however, be the first thing you want to evaluate. To each their own ... this is how I roll though. This is not meant to be a how-to-use a base theme, nor is it meant to judge whether AT is better than Omega or better than this or better than that. All base themes have value to the team who created them. Most are also relevant to a larger community of themers. If you include different criteria when you are evaluating base themes, I'd love to hear from you.
  1. Download the base theme (usually with Drush) and look for a README file. If there is one—read it.
  2. Poke at the theme files but do not read comprehensively yet.
  3. Install the base theme and set it as your site’s default. Check it out. Repeat for any starter kits or alternate options that ship with the theme.
  4. Examine the default state of the theme applied to your Web site and look for helper info—for example region names printed out or wireframe borders. Omega ranks high on this test, Adaptive Theme ranks low. That doesn’t mean the themes you can build from this base theme will be better or worse, I just like to *see* how a theme will render and this is a quick no-code test.
  5. Check the theme settings page for what can be controlled from the UI—and more importantly what the theme expects you to control from the UI. For example: the width of a region may be controlled from a theme setting, or you may hard code it in your page template file. In NineSixty, for example, it’s hard coded. I’m cool with that when I just want to bang out a theme (or prototype a design). In Omega there are zones and regions and configurable widths in the administrative UI. This is also good, but different.
  6. How does the default theme behave with content? Often I skip this stage on a quick review, but Drush + Devel Generate makes it so easy to do that you might as well chuck some content into the site and see what happens.
  7. Finally I look at the code. You can definitely use validation checks, but I usually skip validation and assume things will be okay-ish out of the box. You may want to stop and make sure the code is going to be compliant with various standards and your personal moral code.
  8. What CSS is provided, and how is it structured? Is there one big CSS file, or lots of little files? Is there rtl support? (Do you even need right-to-left language support? Are you sure?)
  9. What tpl.php files are provided? What custom variables are used? Are the custom variables documented in the header of each template file, or do you need to know the core variables off-by-heart and guess at what’s provided by the theme? You may need to dig around in the file template.php to figure out how the variables are built, how core variables have been manipulated, and what each of the variables in the template files is actually doing.
  10. Now that you have an overview of how things fit together: think about how you build/receive your designs. If you use 17-column designs you will not be happy with a 12-column CSS grid framework. If you care about lean, semantic markup, mothership might be better than Zen for your workflow. Remember you are trying to save yourself work—if the base theme assumes “unnatural”-for-you workflow, choose a different base theme. Keep looking until you find something that “clicks” with how you work (you may even need to create your own).
  11. Rough out your last three designs with the base theme. Mentally (or on paper) sketch out how you would have built the design using the base theme you are evaluating. Remember you can add, or remove, (almost) any region, variable or markup you don’t like…but if you have to change a lot, ask yourself if this is the right base theme for you.
And there you have it: the steps I go through when evaluating a new base theme for Drupal. In the video (below) I take a peek at currently popular responsive base themes AdaptiveTheme and Omega using my "from a themer's perspective" criteria that I outlined above. Can't see the video in your reader? Click here to view the video. If you're interested in finding out more on how to create a mobile-friendly, responsive web site faster by using base themes, sign up for my new workshop Responsive Web Design for Drupal.

Accolades

I just wanted to tell you that I have had a true "Ah-HA" moment, on page 33 of SBE Guide: Community Site. After reading and typing and writing notes and going back again and again, all of a sudden I am looking at the code and I SEE it. I just couldn't put all the pieces together before. I could see what was what (html, php, conditional statements) but I couldn't get my head around how it related to the site name banner up above. Like, I could see all the moving parts, but not the whole. Thank you thank you thank you. Thought I'd share my happiness :) - Rachel, student in the SBE program

Recent Blog Entries

Ebooks

  • Microsite
  • Building the Beckon Web Site
  • PSD to Drupal Theme workbook
  • Theming the Contact Form
Nov 04 2011
Nov 04

I just wanted to tell you that I have had a true "Ah-HA" moment, on page 33 of SBE Guide: Community Site. After reading and typing and writing notes and going back again and again, all of a sudden I am looking at the code and I SEE it.

I just couldn't put all the pieces together before. I could see what was what (html, php, conditional statements) but I couldn't get my head around how it related to the site name banner up above. Like, I could see all the moving parts, but not the whole.

Thank you thank you thank you.

Thought I'd share my happiness :)

- Rachel, student in the SBE program

Nov 03 2011
Nov 03

Earlier this week I did a private launch for a brand new workshop and now I am happy to extend the registration to you as well. Responsive Web Design for Drupal is one of the first (if not the first) workshop of its kind that teaches you how to build responsive themes for Drupal 7 sites. This workshop is for freelance web designers whose clients are begging them to create mobile sites ... and for those who are afraid they might be asked.

This course is perfect for freelance web designers who need a little structure to learn responsive web design. You have experience building web sites but you’re overwhelmed by the thought of having to learn yet another web technology. You typically build Web sites for $5k-$50k with a very small team (typically fewer than 5 people and sometimes it's just you). You learn by doing, but don’t want to charge a client to learn how to build responsive web sites in case it goes wrong and you end up having to do loads of work for free on a site that never works (the idea of bidding on a project to “learn” a new skill actually makes you hyperventilate because of that one time where you did just that and you were thoroughly punished and almost lost your shirt).

You're definitely working in the web industry. This course is not for hobbyists who want casual information. This if for professionals who are under the gun to deliver responsive web sites now. If you’re a hobbyist, buy the 2nd edition of the book Front End Drupal when it comes out.

This course will give you the specific skills you need to build new, responsive themes and retrofit old themes to be mobile-friendly. You will be able to attract new clients who are looking to attract the mobile market. Don't forget your existing clients too: you will be able to work with your current clients to upgrade their current sites to mobile-friendly designs.

This workshop is at-your-own-pace. You’re never behind. It includes step-by-step instructions that respect the time you can commit to learning the new content. (But if you’re an information junkie, don’t worry. We’ll include lots of links to some of the best information available on the Web today as well as two free bonus workbooks (Building and Theming a Micro Site with Drupal 7 and PSD to Drupal Theme). )

There's more information on the registration page: Responsive Web Design for Drupal. I look forward to seeing you in class.

Oct 14 2011
Oct 14

I just wanted to tell you that I have had a true "Ah-HA" moment, on page 33 of SBE Guide: Community Site. After reading and typing and writing notes and going back again and again, all of a sudden I am looking at the code and I SEE it.

I just couldn't put all the pieces together before. I could see what was what (html, php, conditional statements) but I couldn't get my head around how it related to the site name banner up above. Like, I could see all the moving parts, but not the whole.

Thank you thank you thank you.

Thought I'd share my happiness :)

- Rachel, student in the SBE program

Oct 13 2011
Oct 13

Continuing on from yesterday's post on my Theming Philosophy of building themes that are budget-appropriate, accessible and responsive, let's jump into base themes.

Yesterday Megan confessed, "I often suspect that there must be something big that I'm missing with base themes. I've just felt a lot better about my process since I stopped trying to use them."

Base themes are merely a set of defaults for your own theme. You can even create your own base theme with your favourite preset or default values. I like to think of them as a cheater kit. When using a base theme you'll want to find one that has the same approach to you in terms of organizing files, overwriting markup, etc. If you feel like you're fighting with the base theme, you've got the wrong one.

I use the following base themes for specific reasons:

  • Zen has amazing documentation. This was the first base theme I worked with and still find its documentation useful.
  • NineSixty is my go-to theme for quickly banging out just about any theme. The documentation is decent, but Zen does a better job of explaining the ins-and-outs of using base themes in Drupal.
  • Fusion is my go-to theme when I will be handing off the site to someone else to maintain who is tech savvy and may need to update the layout later on. They have a great combination of default regions and the tight integration with Skinr is perfect for a number of clients I've worked with (I also use Panels for this same reason).

At some point each of those base themes will be responsive as well; however, if your time line needs a responsive theme NOW, check out Omega and Adaptivetheme. Laura also pointed out the following wiki page: What is the best starter theme for responsive web design in Drupal?

I would be remiss if I didn't point out morten's base theme Mothership which is perfect for markup fetishists. But there are LOADS more than just these six base themes. A mostly complete list of all base themes is available from Starter Themes and you can test out a few of the more popular ones at Drupal Starter Themes. In reality though any theme can be used as a base theme! For example: right now I'm working on some documentation on manipulating forms. I used Bartik as my base theme so that I wouldn't have to hack core to implement my changes.

So how did I pick my top three base themes? To be honest: initially it was in part because of the people working on the projects. JohnAlbin, Todd Ross and the TNT team are all excellent people. I tend to be interested in the projects my friends are working on. (That doesn't mean I don't like the makers of other base themes!!) The base themes are also different enough that they are each worthy of learning inside-and-out as separate tools in my Drupal toolkit. Think of it as different kinds of pliers in your toolbox...you might be able to get away with a needle nose plier when you're ... actually I shouldn't try using tool analogies as I have no idea when you'd use a needle nose plier vs. flat nose pliers and had to look it up on Wikipedia. Hopefully you sort of understand what I mean though...

If you'd like to hear more about my Drupal toolkit from my Acquia webinar PSD to Drupal Theme you can watch it here. You can also read an article that I wrote about converting your PSD to Drupal theme for Drupal Watchdog.

Oct 12 2011
Oct 12

In my webinar yesterday with Acquia I talked about my theming philosophy. The webinar had over 900 attendees, so there wasn't a lot of room for discussion. I thought I'd kick off a series of blog posts where we can discuss some of the topics I covered in the talk. First up: my theming philosophy.

Regardless of whether I'm just a lazy front end developer, or a worker bee who values the contribution of the whole hive, I tend to do as little custom work as possible when building my themes. Instead, I pick the best base theme for the site I'm building, create a minimum viable theme (touching the least number of tpl.php files possible) and then theme the remainder of the site based on the user experience. Having a strong user story is really important for this style of theming. You must know every page a visitor will see and ensure that the pages all look right (or at least right enough for your time/money budget).

When building out my themes I focus on three main goals. Even though I see each of them as related to web design, they are not part of the actual design of the site. For example: I don't include user goals or business goals because these are goals that relate only to the theme itself (which is built after those design decisions have been made).

Budget-Appropriate Web Design
  • Know your Drupal toolkit. Know your budget.
  • Focus on the biggest elements first.
  • Work closely with your designer and your client to make sure you get the important things right.
  • Theme with the markup you have, not the markup you'd like to have. (This is via Laura Scott.)
  • Pixel perfect design is for print. Get over it.
Accessible Web Design “Accessible web design refers to the philosophy and practice of designing web pages so that they can be navigated and read by everyone, regardless of location, experience, or the type of computer technology used.”
Australian Human Rights Commission
  • Know your guidelines (508 or WAI).
  • Use a checklist.
  • Use an automated testing suite.
  • Test with users.
I've cribbed a list of accessibility testing tools from my new book. Let me know if you know of other good ones. Responsive Web Design “Any approach that delivers elegant visual experiences regardless of the size of the user’s display and the limitations or capabilities of the device” zeldman. This is a new area for everyone. In the webinar when I asked if people were building (or being asked to build) responsive themes 200+ people raised their hand.

If you'd like to hear more about each of these points, you can view the recording of the webinar here.

This is definitely not the only approach to theming. My guess is that others may put more emphasis on semantic markup, or future-proofing theme files for layouts that don't exist yet. What approach do you take when building your Drupal themes?

Sep 19 2011
Sep 19

Last week I teamed up with Lullabot for a super awesome give-away: five copies of my latest book (which *I* don't even have a copy of yet) were given away via Twitter. The contest is closed, but follow @diwd as I'm pretty sure they've got something else up their sleeve (*hint*hint*).

What does this have to do with a make-over? Well. Some time ago I whipped together a quick (and really dirty) theme for my personal site. I was trying to separate my "tech" writing from my "human" (craft/cooking/gardening) writing for various reasons that made a lot of sense at the time. And then I got really busy doing a lot of other things and pretty much stopped blogging. (Sound familiar?) I'd been trying to think of a way to solve the front page, but it was just never really a priority.

Until last Friday. Sweet mother of a cow, the twitter contest for my new book was pointing to my really awful home page! So I started trawling through free Drupal themes and static templates and I may have even started looking at WP themes that I could convert to Drupal. None of them were quite right. I was sad. My personal home page was still ugly and I didn't know how to make it suck less *immediately*.

Google Alerts to the rescue. Today I got an alert for "Drupal theming" letting me know that Drupal Style had updated their site. I clicked through to see what they were up to and found the PERFECT theme for my needs.

Here are the modifications I made:

  • Created custom images for the featured blocks (one for each of the books, one for twitter and one for my very neglected blog). In case you're curious, the twitter bird is from here; and the RSS icon is from there (a great set which Eaton told me about).
  • Custom block template files to put the images in the right spots for each of the featured blocks in the footer.
  • Customized the template page-front.tpl.php to remove the content-related variables and update the page title to use a bookmark-friendly title.
  • Customized the template page.tpl.php to move the "featured blocks" region to the bottom of the page, and completely removed the banner from inside pages. (This means I don't have to worry about customizing the blocks to only show on some pages.)
  • Updated the CSS to make the content appear as dark text on a light background (matches the mostly white front page) and adjusted the height of the featured footer blocks.

I'm sure I'll continue to make the odd tweak here and there, but that's basically it.

Total time from finding the theme to relaunch: about three hours. Total time to find a starting theme that "clicked" for me: at least three months.

Have you got a similar story about finding the perfect theme? I'd love to hear it--leave your story in the comments (don't forget to link to your site and the theme you used).

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web