Why Responsive Design?

If you've built a web site in the past several years, you've probably heard of Responsive Design. Coined in 2010 by designer Ethan Marcotte, the term covers a set of techniques that allow one flexible web design to serve many different screen sizes.

In the years since it hit the scene, "responsive" has become the default choice for modern, mobile-friendly sites. With that visibility, though, comes misunderstanding and controversy! Some proponents treat responsive design as a silver bullet for every project's tough problems, while detractors complain it will limit their grand vision. Some clients believe they have to choose between a responsive site or a native mobile app, as if one ruled out the other. And in a few frustrating situations, we've seen totally separate mobile, tablet, and desktop mockups passed off as a "responsive" approach.

At Lullabot, we believe that responsive design is a critical part of future-friendly web publishing. Making the most of it requires understanding which problems it solves, which ones it doesn’t, and how it fits your project’s needs. In this article we'll take a look at how we build responsive sites, correct some common misconceptions, and explain the real benefits for your projects.

What is "Responsive," anyways?

Ethan Marcotte's seminal article and follow-up book define specific techniques that make a site responsive. Both make great reading for anyone who wants to dig into the details. At a high level, we can boil it down to a handful of principles.

Build a fluid, flexible layout.

Ever since the first Photoshop mockup was used to sell a site design, web developers have been creating "fixed width" layouts that target specific screen sizes. When space-constrained mobile browsers hit the market, they had to create custom mobile sites with stripped-down designs. Responsive design starts with a layout that stretches and squishes to fit any screen, often relying on percentages and ratios rather than fixed sizes and positions.

Media queries tweak elements when the layout breaks.

Stretchable, squeezable fluid layouts can't cover every extreme: a design that looks great on a 27" desktop monitor might look impossibly cluttered on a 4" phone. Designers identify situations where the fluid design breaks, and use conditional CSS rules to add special styling instructions for those "breakpoints." On a tall-but-skinny smartphone, for example, sidebars might be moved to the bottom of an article to leave more space for text. On a wide desktop screen, photo captions might be moved beside images to take advantage of the extra room.

Images and media must be flexible.

Giant fixed-width images, embedded media players, and clunky widgets can all break your smooth, fluid layouts. Styling for these elements should use percentages and ratios, too—ensuring that they conform to fit the responsive layout they're placed in. Tools like FitVid.js and the new HTML Picture element can make this part easier.

Respond to capabilities, not specific devices.

The most important principle is simple: responsive design plans for scenarios and capabilities, rather than specific hardware devices. Instead of "sniffing" for iPhones and generating custom HTML and CSS, a responsive site uses one standard set of HTML. Conditional CSS rules and client-side scripts account for the special cases like low-resolution portrait displays, mobile devices with GPS capabilities, and so on. That ensures the design will respond intelligently to any device that matches the right criteria—including newly released ones—and the long tail of older devices often ignored by the latest design trends.

Although device detection, tailored markup, and other techniques can be layered on top of a responsive design, a strong responsive foundation is the most reliable starting point.


Complementary techniques

In addition to those core principles, our team has discovered that certain approaches blend well with responsive techniques. Not every responsive design project works this way, but the ones that do are much more likely to succeed.

Plan the content before the presentation.

This is good advice for any project, but it's especially important for responsive sites. Before we start wire framing, we want to understand the site's most important messages, know just what kinds of content will be used to communicate them, and decide how each element will be prioritized. We use content like building blocks to construct pages, rather than pouring it into the design like cake batter.

Design for mobile.

"Mobile-first" design doesn't mean that every site needs to look like a skinny river of text. Rather, it means keeping the most constrained scenario in mind as the design evolves. Planning around those limitations first forces important decisions about priorities and the relationships that connect each element in the design. It's much easier to start with a streamlined mobile layout, layering additional elements as screens get larger, than it is to squeeeeeeeze a busy desktop design onto a tiny touch screen.

Design components, not just pages.

Identifying the shared visual components that are used throughout the design, then planning how those components will behave in different contexts, can pay off handsomely. This modular approach can help separate the high-level work of building responsive layouts from the fiddly tweaking and testing needed for each reusable component. Techniques like Style Tyles can be used to explore the aesthetics while the components are being built

Build working wireframes.

Napkins and PDFs are great for rough concept sketches, but once a responsive design gets serious, nothing beats HTML and CSS. Viewing the wireframes on several devices, rather than flipping through separate wireframes for each breakpoint, helps stakeholders envision how the design will work in the real world. It also helps keep a design team honest, ensuring that the ideas they come up with will really work in a browser.

Use server-side tweaks to lighten the load.

Although responsive design is defined by its use of browser technologies like CSS, server-side logic can still help. When a layout needs to be personalized for the logged-in user, for example, conditional logic on the server can still supply a different layout template. Client-side scripts can also request specific widgets or content from the server if they're needed, avoiding the cost of downloading every piece of content and media on devices that will only show a smaller subset. Designer Luke Wroblewski calls this technique RESS: REsponsive design and Server Side components.

Understanding the challenges

Like many other techniques, Responsive Design is an important tool in our toolbox, not a cure-all for every problem ailing the web. Before diving into your first responsive project, it's important to keep some caveats in mind.

Building a desktop-only site is still cheaper… in the short term.

Creating a design around a single screen size will always take less time than one that accounts for many sizes. In some cases, a skilled team can also produce a stripped down “mobile design” without breaking the bank. The economics of responsive design make the most sense when additional screen sizes (like tablets) enter the mix, and when your desktop and mobile sites must offer equivalent functionality.

It isn't as flexible as designing one-off sites for every device.

A design that accounts for multiple displays and resolutions can’t handle extreme variations in layout and content from one size to another. Some design choices—like a hard and fast reliance on mouseover effects or swipe gestures—won’t work on every device, either. Nevertheless, few organizations have the resources and coordination to built a truly custom experience for every display size and device type. In addition, Google’s own research demonstrates that most users want consistency across devices when they use a web site; the more your mobile and desktop sites differ, the more difficult it can be to switch from one to the other.

Speed and mobile-friendliness aren’t automatic.

Responsive design can bring lots of benefits for mobile users, but making sure the site loads quickly still takes work. There’s nothing preventing a bad responsive implementation from burying low-bandwidth mobile users under high-res images, auto-play videos, and third-party Javascript. Techniques like conditional loading of media assets, testing restricted-bandwidth scenarios, and setting a clear performance budget before you build, are all critical.

Integrating ads takes extra planning.

For sites that rely on ad revenue, responsive design can complicate matters. Although there’s nothing preventing you from scaling ads up and down, or shuffling them around on the page as the layout changes, their aesthetic impact can be tougher to predict without extensive testing. The density of advertisements users have grown to accept on some desktop sites can be overwhelming on a small screen, and advertisers who pay a premium for specific spots on the page may need hand-holding to understand the breakpoint-to-breakpoint changes in a responsive layout.

Don’t be distracted by the app argument.

Mobile developers have been locked in a “Web apps versus native apps” tug-of-war ever since the iOS App Store launched in 2008. Responsive design is often roped into that argument, even though it’s a separate issue. These days, even native mobile apps use responsive design principles as often as web sites: the average Android app needs to cope with hundreds of different display sizes and resolutions, after all. Whether your organization needs a mobile app shouldn’t change the way your web site handles device and screen-size proliferation.

Should your site be responsive?

Let’s keep this one simple: Yes. Responsive design is the most cost-effective way to deal with the widest possible array of devices, and the simplest way to future-proof your web site. On their Responsive Design Podcast, Karen McGrane and Ethan Marcotte have talked to dozens of organizations about the challenges and the payoffs: there’s no denying its effectiveness.

"I can tell you that it worked way more emphatically than I would have—even in my wildest dreams—have hoped," said Mark Jannot of the National Audobon Society on a recent episode. "The percentage of mobile [traffic] doubled, from fifteen percent to thirty percent, essentially immediately."

Of course, that doesn’t mean that you can’t or shouldn’t pair it with techniques like native mobile apps, device and feature detection to enable additional features, server-side tailoring of site markup, and so on. Responsive techniques allow you to build a solid foundation for your web presence, one that will handle a wide range of scenarios as gracefully as possible. When that baseline is established, you can focus your customization resources where they’ll do the most good, rather than scrambling to catch up whenever a new device come into vogue.

Write Unit Tests for Your Drupal 7 Code (part 1)

Large software projects lead to many features being developed over time. Building new features on top of an existing system always risks regressions and bugs. One of the best ways to ensure that you catch those before your code hits production is by adding unit tests.

In this article series I will guide you through adding PHPUnit tests to your Drupal 7 modules. This article explores what unit tests are and why they are useful. And then looks at how to structure your Drupal 7 code in a way that is conducive to writing unit tests later on.


I encourage you to start testing your code. Here are the most important points of the article:

  • Start writing object-oriented code for Drupal 7 today. In your hooks you can just create the appropriate object and call the method for that hook.
  • Fake your methods to remove unmet dependencies.
  • Leverage PHPUnit to ease writing tests.
Unit tests to the rescue

In Drupal 7 core, Simpletest was added so everyone could write tests for their modules. While this has been a great step forward, executing those integration tests is very slow. This is a problem when you want to do Test Driven Development, or if you want to run those tests often as part of your workflow.

A part of Simpletest is a way to write unit tests instead of integration tests. You just need to create your test class by inheriting from DrupalUnitTestCase, but its drawback is that most of Drupal isn’t available. Most Drupal code needs a bootstrap, and it’s very difficult to test your code without a full (slow) Drupal installation being available. Since you don’t have a database available, you can’t call common functions like node_load() or variable_get(). In fact, you should think about your unit tests as standalone scripts that can execute chunks of code. You will see in the next section how PHPUnit can help you to create these testing scripts.

PHPUnit has you covered

In the greater PHP community, one of the leading unit test frameworks is PHPUnit, by Sebastian Bergmann and contributors. This framework is widely used in the community, attracting many integrations and extra features, compared to the aforementioned DrupalUnitTestCase.

Daniel Wehner comments on these integrations saying:

Since Drupal 8 started to use PHPUnit as it's unit test framework. One advantage of PHPUnit is that there are tools around which support it already.

Here is a screenshot of PhpStorm where you can see how you can execute your tests from the IDE:


PHPUnit is the PHP version of the xUnit testing framework family. Therefore, by learning it, you will be able to leverage that knowledge in other languages. Besides there’s a big documentation and support base for xUnit architectures.

The best part of PHPUnit is that it allows you to write easy-to-read test classes efficiently, and it has many best practices and helper tools –like the test harness XML utility–. PHPUnit also comes with some handy tools to mock your objects and other developer experience improvements to help you write your tests in a clearer and more efficient way.

To use PHPUnit with Drupal 7 you need to write object-oriented code. The next section will show you an example of the dependency problem, and one way to solve it using OOP with the fake object strategy.

A change in your mindset

The hardest part of unit testing your Drupal code is changing your mindset. Many developers are getting ready to use object oriented PHP for Drupal 8, but they keep writing procedural code in their current work. The fact that Drupal 7 core is not as object oriented as it might have been does not imply that custom code you write must also be procedural and untestable.

In order to start unit testing your code, you need to start coding using OOP principles. Only loosely coupled code can be easily tested. Usually this starts by having small classes with clearly defined responsibilities. This way, you can create more complex objects that interact with those small pieces. Done correctly, this allows you to write unit tests for the simple classes and have those simple classes mocked to test the complex ones.

Unit testing is all about testing small and isolated parts of the code. You shouldn’t need to interact with the rest of the codebase or any elements in your system such as the database. Instead, all the code dependencies should be resolved through the use of mock objects, fake classes, dummies, stubs or test doubles.

Mock objects avoid dependencies by getting called instead of the real domain objects. See the Guzzle’s documentation for an example.

Gerard Meszaros writes about test doubles in these terms:

Sometimes it is just plain hard to test the system under test (SUT) because it depends on other components that cannot be used in the test environment. This could be because they aren't available, they will not return the results needed for the test or because executing them would have undesirable side effects. In other cases, our test strategy requires us to have more control or visibility of the internal behavior of the SUT.

When we are writing a test in which we cannot (or chose not to) use a real depended-on component (DOC), we can replace it with a Test Double. The Test Double doesn't have to behave exactly like the real DOC; it merely has to provide the same API as the real one so that the SUT thinks it is the real one!

In typical Drupal 7 modules, which is our System Under Test (SUT), there are many parts of the code that we want to test that rely on external dependencies –our depended-on component (DOC). Good examples of those dependencies are Drupal core, other contributed modules, or remote web services. The fact that a method calls a Drupal function, such as cache_get(), makes it very difficult for the test runner to execute that code, since that function will not be defined during the test. Even if we manually included includes/, the cache_get() function might require other include files or even an active database connection.

Consider the following custom class:

class MyClass implements MyClassInterface { // ... public function myMethod() { $cache = cache_get('cache_key'); // Here starts the logic we want to test. // ... } // ... }

When we call myMethod() we will need to have the database ready, because it is calling to cache_get().

// Called from some hook. $object = new MyClass(); $object->myMethod();

Therefore, myMethod(), or any code that uses it, is not unit testable. To fix this, we wrap cache_get() in a class. The big advantage of this is that we now have a CacheController object that deals with all of our cache needs by interacting with the Drupal API.

class CacheController implements CacheControllerInterface { /** * Wraps calls to cache_get. * * @param string $cid * The cache ID of the data to retrieve. * @param string $bin * The cache bin to store the data in. * * @return mixed * The cache object or FALSE on failure. */ public function cacheGet($cid, $bin = 'cache') { return cache_get($cid, $bin); } }

And the custom class becomes:

class MyClass implements MyClassInterface { // ... public function __construct(CacheControllerInterface $cache_controller) { $this->cacheController = $cache_controller; } // ... public function myMethod() { $cache = $this->cacheController->cacheGet('cache_key'); // Here starts the logic we want to test. // ... } // ... }

The calling code stays the same.

Our test class will execute myMethod() with a fake cache controller that doesn’t need the bootstrap or the database.

// Called from the PHPUnit test case class. $cache_controller_fake = new CacheControllerFake(); $object = new MyClass($cache_controller_fake); $object->myMethod();

What our fake cache controller looks like:

class CacheControllerFake implements CacheControllerInterface { /** * Cache array that doesn't need the database. * * @var array */ protected $cache = array(); /** * Wraps calls to cache_get. * * @param string $cid * The cache ID of the data to retrieve. * @param string $bin * The cache bin to store the data in. * * @return mixed * The cache object or FALSE on failure. */ public function cacheGet($cid, $bin = 'cache') { return isset($this->cache[$bin][$cid]) ? $this->cache[$bin][$cid] : NULL; } }

The key is that the test will create a fake object for our CacheController and pass it to the SUT. Remember that you are not testing cache_get() but how the code that depends on it is working.

In this example, we have removed the dependency on includes/ and the existence of the database to test a method that calls to cache_get(). Using similar techniques you can test all your classes in your module.

The next article of the series will get deeper into the matter by covering:

  • Mocking tools like: PHPUnit mocking objects and the Mockery project.
  • Dependency injection in Drupal 7 to pass your dependencies easily.
  • Drupal Unit Autoload to reduce the number of classes to mock.
  • A real life example that applies all these concepts.

Do you add unit tests to your Drupal 7 modules? Share your experience in the comments!

The New

React.js, CouchDB, Node.js, de-coupling Drupal; if any of that sounds cool to you, then this is the podcast for you. Kyle Hofmeyer gathered a several Lullabots together, who helped create the new, to learn what kind of wizardry was used to make this thing purr like a happy kitten. Jared Ponchot talks about the advantages this process provided for him and his design team. Sally Young talks about the guts of the site and the magic that went in to making this de-coupled Drupal site a success. We are also joined by Kris Bulman, Wes Ruvalcaba, and Betty Tran as they share their experience building the site. From front-end advantages to lazyboyDB, this podcast has it all.

Announcing The New

Mmmm… love that new website smell! Some history

It's been nearly 10 years since we launched our first company website at During that time, we've done five full redesigns of the site. The company has grown from two people to 62. We've expanded from a small Drupal consulting and education company to a full-service agency with a complete Design team, dedicated front-end developers, and of course, the expert Drupal back-end development which has always been our foundation.

As we've grown, our site design has reflected our focus and skills. The first site that Matt and I put together back in 2005 was intentionally sparse – not exactly beautiful, but functional and simple to maintain for just 2 or 3 people. As we hired talented designers and skilled front-end developers, site redesigns became more complex. In 2010, we split our Drupal education services into Drupalize.Me and the main focus of became our client services work, showcasing our design and development projects and sharing insights from our team.

Revving up the new

The newest iteration of is our most ambitious to date. As with most of our client engagements, the project started with research. Our Design team interviewed existing and potential clients, site visitors, and the Lullabot team to understand how people were using our site – what they wanted to get out of it, and why they visited. Our team distilled all they'd learned into goals and early wireframes for the site. They then worked with our Development staff to try to come up with the most flexible way of achieving these goals so that we could have full control of the site in ways that Drupal often doesn't afford. They wanted full <html> to </html> blue-sky design of any arbitrary page on the site without losing Drupal's amazing content management capabilities.

The technical team settled on a decoupled, isomorphic approach using Facebook's React, Node.js, CouchDB (a noSQL database) and Drupal as the backend CMS.

Content management is what Drupal does best, and this happens through a purpose-built subsite where the Lullabot team can login and post articles, podcasts, and manage their bios. Drupal pushes content into CouchDB, which exposes a REST API for React to consume. React is an isomorphic library (its code can run both in the server and the client), which means that when a visitor first visits the site, they receive the html of the entire page. Then, the rest of the navigation happens client-side, updating just the parts of the page which are different from the current one. Furthermore, React is written to be completely backward compatible with older browsers.

Our clients are often in need of API-driven native mobile apps, television-based apps, and content ingestion on connected devices. We've implemented these things in less holistic ways with our clients in the past. But the new gave us a chance to experiment with some methodologies that weren't quite tried-and-tested enough to recommend to our clients. But now that we've had a chance to see the type of flexibility they give us on, we'll be adding this to the array of architectural strategies that we can consider for our clients in the future.

Look ma, no hands!

The results are amazing; high-speed, high-performance, and superlative flexibility. In layman's terms, this means our Design and Front-end people can go crazy – implementing blue-sky ideas without the usual Drupal markup constraints. The new site is fully responsive. Articles and portfolio work pages can have giant, dazzling, full browser-height background images or videos. Articles have big text that is easy to read on any scale from large desktop monitors to the smallest phone screens. Furthermore, we did everything with an eye toward blazing fast page loads. We omitted jQuery, trading convenience in the development process for speedy page loads. Then we looked at every http request, every image, every library to make sure our website was as snappy on an older smartphone as it was on the desktop. Best of all, we off-loaded much of the heavy lifting to the client-side with React.

Design-wise, the new site is uncluttered, sparse, and relatively simple. But whether you're looking for our vast archive of articles or podcasts, information about what services Lullabot offers, who we've worked with and what we've done, or you're curious to know what it's like to work at Lullabot, it's all there.

Over the coming months, we will be writing a series of articles and doing a few podcasts talking about different aspects of the new site. Please subscribe to the Lullabot email newsletter below and you'll be the first to know when new articles are published.

SEO and Customer Data

In this podcast, hostess Amber Matz talks with Andrew Wilson, Senior Account Manager at Drupalize.Me about SEO, and gathering and analyzing customer data. Learn about how structured data and rich snippets can enhance search results, along with some important things to know about how Google works. We talk about some hard SEO lessons learned here at Drupalize.Me. We also discuss the aggregated data in Google Analytics versus user-specific data and tracking provided by services like Kissmetrics and, and how, as a business, you can learn more about your customers through gathering and analyzing site visitor data with an ultimate goal of serving your customers and clients (potential and present) more effectively.

Switching Drush Versions

Different versions of Drupal require different versions of Drush, here’s how to make the switch easily

Stu Keroff on Asian Penguins

In this episode of Hacking Culture, Matthew Tift talks with Stu Keroff about a Linux User Group for Asian middle-school students called Asian Penguins. The kids learn not only how to use Linux, but also maintain more than 30 Linux computers for their school and provide Linux computers to local families that cannot afford a computer. This episode is released under the Creative Commons attribution share alike 4.0 International license. The theme music used in this episode comes from the Open Goldberg Variations. The musical interludes all come from “Reverie (small theme)" by _ghost ( under CC BY license. "Heartbit" by Alex featuring Onlymeith ( under CC BY-NC license.

Project Management

In this week's Drupalize.Me podcast, hostess Amber Matz chats about all things Project Management with Seth Brown (COO at Lullabot) and Lullabot Technical Project Managers Jessica Mokrzecki and Jerad Bitner. To continue the conversation, check out Drupalize.Me's series on Project Management featuring interviews and insights from these fine folks and others at Lullabot.

Drupal 8 Theming Fundamentals, Part 2

In our last post on Drupal 8 theming fundamentals, we learned to set up a theme and add our CSS and JavaScript. This time around we’re talking about the Twig templating engine, how to add regions to our theme, and then finish with a look at the wonderful debugging available in Drupal 8.

The Cutting Edge of the Web: VR

Back in October, I received the Oculus Rift DK2 for my birthday and found what I think will be the future of how we build websites, interact with customers, and communicate with each other. I found a community of enthusiasts who are building virtual worlds with the very same concepts we use to build two-dimensional websites today. This community is pushing the boundaries of the web in a way that is unlike any other, and we’re having an absolute blast discovering the possibilities.

Holly Ross on the Drupal Association

In this episode of Hacking Culture, Matthew Tift talks with Holly Ross, the Executive Director of the Drupal Association, about the Drupal community, the Drupal Association, non-profits, business, tax codes, and more. They get into some controversial issues, and some of Holly's answers may surprise you!

What is an isomorphic application?

Javascript was traditionally the language of the web browser, performing computations directly on a user’s machine. This is referred to as “client-side” processing. With the advent of Node.js, JavaScript has become a compelling “server-side” language as well, which was traditionally the domain of languages like Java, Python and PHP.

Importing CSS Breakpoints Into Javascript

There are a lot of challenges within responsive web design, and one that that has constantly been a pain is triggering JavaScript based on the current CSS media query breakpoint. The problem is that the breakpoints are in CSS, which JavaScript has no native way to access. Many solutions (including window.matchMedia(), and Enquire.js) involve declaring your breakpoints in both CSS and JS, or require IE10+.

Let's Chat About Web Accessibility

Join Amber Matz as she chats with web accessibility aficionados Mike Gifford, Chris Albrecht, and Helena Zubkow about what web developers and Drupalistas can do to build more accessible web sites. How has web accessibility changed over the years? Who is being left behind? What are some common gotchas? What are some easy ways to get started testing for accessibility? All these questions and more are discussed in today's podcast. Don't forget to check out the links and resources in the show notes for all sorts of useful things mentioned in our discussion.