Drupal Fire - Quick Roundup from important Drupal blogs and sites

Subscribe to Drupal Fire - Quick Roundup from important Drupal blogs and sites feed
News, views, tips, and tricks from the best Drupal developers, designers, and writers. All Drupal, all the time.
Updated: 2 hours 6 min ago

Weekly Watercooler #139

Mon, 2016-03-28 19:27

Four Kitchens (via DrupalFire)

SXSW came and went faster than “winter” for Austin, TX. That didn’t stop us from making writing about some BIG plans and ideas we’ve been working on.

Categories: Drupal Universe

Launch announcement: Successful Farming at Agriculture.com

Fri, 2016-03-25 21:16

Four Kitchens (via DrupalFire)

We are proud to announce the launch of Successful Farming at Agriculture.com. Working with Meredith Agrimedia’s Successful Farming magazine and Agriculture.com’s digital content, Four Kitchens helped unify the brands and provided a transition strategy to integrate the two identities …

Categories: Drupal Universe

Breaking out of the office

Thu, 2016-03-24 20:19

Four Kitchens (via DrupalFire)

Four Kitchens is about to take its biggest step in a years-long journey towards changing how we collaborate as a team: We’re letting go of our physical office space and becoming a fully #DistributedTeam…

Categories: Drupal Universe

How to try out AMP with Drupal

Thu, 2016-03-24 16:18

Lullabot (via DrupalFire)

What is AMP, and why should I give it a try?

In “AMPing up Drupal,” Matthew Tift explained what AMP is, and how we worked to create a module, theme and PHP library to use AMP with Drupal. Spoiler alert: AMP stands for Accelerated Mobile Pages, and it’s an open source project developed to make web pages super fast on mobile. It’s particularly geared towards content like articles or informational pages, rather than e-commerce or applications. If you haven’t read Matthew’s article, do so now, as from here on out, I’ll assume you know the basics of AMP.

Lullabot released the Drupal 8 version of the AMP module and theme on February 26, and we are delighted to announce that a Drupal 7 version is now available. These are still beta versions, and we hope to continue improving upon them. We think they’re at a point where it’s worth giving them a try, even if only to test how it works locally or in a feature branch for your site.

I’m going to walk you through how to get started. Setting up your site for AMP takes a few steps, but you get a good deal of control over how your AMP pages look as a result. This walkthrough will explain the process step-by-step, providing a little more context than you might find in the README. For the bold and adventurous, you’re welcome to try this out straight from the Drupal 7 README or the Drupal 8 README

After the walkthrough, I’ll share a few thoughts on why I think you should try out AMP.

Setting up AMP with Drupal

The first key thing to understand is that AMP does not replace your entire site. AMP exists to provide a lightning fast way for site visitors to view articles and other content-focused pages.

At its essence, the AMP module provides an AMP view mode for certain content types, which the site can show when the browser requests an AMP version of a page.

On that AMP view mode, you can select AMP field formatters to take care of converting some of your content so they use the proper AMP tags. The AMP PHP library processes raw HTML, like the content in your body field after it has been filtered and had tokens replaced (if you are making use of the Token module). The library attempts to replace HTML content with AMP HTML components. It filters markup it cannot convert out of the final AMP HTML. This helps ensure the validity of content under editorial control, which may have a wide variety of embedded content.

When visiting pages with AMP-enabled content types, if the URL has ‘amp’ in the query string (e.g. my/favorite/page?amp), Drupal will use the AMP view mode and AMP theme selected on the AMP configuration page (admin/config/content/amp). The AMP Theme project provides an AMP Base theme that takes care of converting some of the larger parts of the page into AMP. For Drupal 8, that’s the html.html.twig, page.html.twig and node.html.twig templates; in Drupal 7, html.tpl.php, page.tpl.php, and node.tpl.php. The theme provides a subtheme aptly named the ExAMPle theme that demonstrates how to customize the appearance of AMP pages with custom styles. You could also create your own custom subtheme with your own styles. Then on the block layout page, you can place a variety of blocks into the regions for the AMP theme you’ve chosen.

That’s the big overview. Let’s dig into the details.

Installing the AMP module, theme and library

If you’ve used Drupal 8, you’re probably already familiar with Composer, a packaging tool for PHP that helps to install dependencies for a project. We’ll use Composer to install a PHP library that converts raw HTML into AMP HTML; Composer will also help to get that library working with Drupal. That’s true both for the Drupal 8 and the Drupal 7 versions of the AMP module.

The workflow we recommend involves using a Drupal module named Composer Manager. A composer.json file within the AMP module declares the dependency on the AMP PHP library. That library in turn has its own dependencies. Other modules that also have their own composer.json files could declare the same library dependencies. So Composer Manager takes care of going through all the modules installed on a site, collecting the info in their composer.json files, and bringing all of that information together so that multiple modules don’t end up installing the same dependencies that might conflict with each other.

However, the AMP module does not explicitly require Composer Manager as a dependency. Alternate workflows can make use of module Composer files without using Composer Manager. For example, Karen Stevenson provides an overview of how to use Composer to manage your entire site installation in her article, Goodbye Drush Make, Hello Composer!

If you are working with Drupal 7, you might find Composer Manager particularly useful. Drupal 8 has a built-in PHP autoloader. This allows you to take advantage of other PHP classes in a project without a require statement that specifies the exact file where that code is located. Composer Manager provides an autoloader for Drupal 7, so that the AMP module can make use of the code found within the AMP PHP library that Composer Manager installs.

Drush makes working with Composer Manager even easier. With Drush installed, several CLI commands, which we will cover below, can help to make use of Composer Manager. In addition, when you enable modules through Drush, Composer Manager can automatically install dependencies.

Whether you are working with a Drupal 7 or a Drupal 8 site in your local development environment, make sure you are using the most recent version of Drush 8, which now works with both Drupal 7 and Drupal 8 sites.

Let’s get ready to set up your Drupal site with AMP. With your local prepped, you can type the following terminal command within the directory where your Drupal site is located:

drush dl amp, amptheme, composer_manager

This will download the AMP module, the AMP theme and the Composer Manager module (if you don’t already have Composer Manager installed).

Next we’re going to enable the first items we’ll need to get started.

drush en composer_manager, amptheme, ampsubtheme_example

Notice we’re not enabling the AMP module yet! We want Composer Manager enabled and working before we do so. We’re also enabling an example subtheme included with AMP Theme: ‘ExAMPle subtheme.’ If you review the code in the subtheme, you can see how to set up custom styles for AMP pages. You can create your own subtheme if you like and install that instead. The default configuration for the AMP module sets the AMP Theme to ‘ExAMPle subtheme.’ So if you just want to try out the AMP module, enabling the example subtheme is a handy way to see how the module and theme work together to provide valid AMP HTML with a custom design.

You should now be able to enable the AMP module using Drush, and when you do so, Composer Manager will take care of downloading the AMP library and its required dependencies. Enabling the module in the UI does not trigger Composer Manager to install dependencies, so Drush is the preferred way to enable the AMP module.

drush en amp

You should get a message about dependencies being downloaded. If that doesn’t happen, then the modules should provide an error message about the AMP library not being available. Here are some things you can try for troubleshooting.

If you are using Drupal 8:

If you are using Drupal 7:

  • Go to the docroot for your site and enter drush composer json-rebuild followed by drush composer-manager install. Check /admin/config/system/composer-manager to verify everything is green. If so, try drush en amp again.

  • You may find it useful to go to sites/default/files/composer and enter composer install if the above doesn’t work. Then try drush en amp again.

Once the AMP library is installed, if you later need to update to a newer version, drush composer-manager update should take care of the update. Review the Composer Manager documentation for additional details.

You should now have the AMP module, AMP theme, AMP example subtheme and AMP library all installed and enabled. Next, we need to configure your site to make use of these new tools.

Configuring your site for AMP

Once everything is installed and enabled, you can find the AMP configuration page at /admin/config/content/amp. The first thing you’ll see is the list of your site’s content types. Take a minute to think about which content types should have AMP versions. It might not be all of your content types! News articles, blog posts and basic content-oriented pages are all great candidates for AMP.

List of view mode on AMP configuration page, including whether they are enabled or disabledView mode information on AMP configuration page in Drupal 8

To enable a particular content type for AMP, click on the “Enable AMP in Custom Display Settings” link. On the next page, open the “Custom Display Settings” fieldset. Check the AMP box, then press Save. This will bring you back to the main AMP config page. You’ll then want to press the corresponding “Configuring AMP view mode” link for that content type. On that page, you’ll be able to select which fields should display and the field formatters that each will use.

 checkboxes for each display mode, as well as Save buttonCustom display settings, found on the default display mode under the Manage Display tab for a content type in Drupal 8

The first thing you’ll want to do is change the body field to use the AMP Text field formatter. There are also custom AMP field formatters for images, videos (file fields) and iframes (text fields). More field formatters may be added in the future. This should help get you started. Some of the field formatters, like AMP Image, have additional options you might want to review by pressing the gear icon, which appears to the right of where you select that field’s formatter.

 list of fields and the AMP field formatters selected for eachIn Drupal 8, on the Manage Display tab for a content type, under the AMP view mode you can select AMP field formatters for each field

This combination of AMP view modes and field formatters is the heart of how your content is transformed into an AMP page. The AMP Text field formatters are particularly important in converting freeform text blocks that might contain embedded content. Some items like Twitter embeds will be automatically converted to the equivalent AMP components. Items with markup that is invalid for AMP, and which cannot be converted by the library into AMP markup, will be filtered out of the markup so that the page will validate as AMP.

Selecting an AMP theme

While the AMP module’s view modes and field formatters take care of the main content of the page, the AMP theme changes the markup outside the main content area of the page. The AMP theme also allows you to provide custom styles for your AMP pages. You will likely want to do that so that your AMP pages have branding similar to the non-AMP pages on your site.

On the main AMP config page, you’ll also want to make sure that the setting for the AMP theme is set to the ExAMPle Subtheme or your custom AMP subtheme. The AMP Base theme changes markup necessary for all AMP-based themes. In Drupal 8, AMP Base uses core’s Stable theme as its parent theme in order to keep the markup as lean and class-free as possible.

Select the AMP theme on the AMP configuration pageOn the AMP configuration page, you can select the AMP theme

If you want to create a custom AMP subtheme with your own styles, take a look at how the ExAMPle subtheme does so. AMP does not allow custom JS, so the main thing you’ll be interested in is providing some custom styles and any markup changes necessary to support those styles. In Drupal 7, custom styles go in amp-custom-styles.css within the css directory at the root of the custom theme. In Drupal 8, the file where you’ll put your CSS is amp-custom-styles.html.twig, in the amp-css directory, which is inside the templates directory at the root of the custom theme. That’s because the CSS is embedded in the head of the html.html.twig file. In order for Drupal 8's Twig template engine to import code into a Twig template like html.html.twig, that code must be in a Twig template (and not another type of file) located in the templates directory of the theme.

Please note that the custom CSS has a maximum size of 50K! So this shouldn’t be all the styles for your entire site, but just whatever minimal styles are needed for AMP pages. If you want to use Sass to generate that CSS, you could definitely do so, as long as it compiles down to the one CSS file needed by the theme. Make sure to review the AMP Project guidelines for styling pages.

After you have the AMP theme selected, go to that theme’s block layout page. You will likely want to review block placement. You probably only need a few blocks: AMP pages are geared towards loading quickly and providing a great reading experience, so extensive menus for navigating the site may appear out of place (and could be difficult to implement without custom JS).

List of regions for the AMP theme, with only a few blocks placed in each regionSelect a limited number of blocks for your AMP theme on the block layout

Let’s check one last thing on the main AMP config page. There’s a checkbox near the bottom that enables full processing of the entire page’s markup through the AMP library. I highly recommend checking this box, as that helps to further ensure your page will be valid AMP HTML. If a module adds an attribute to some template somewhere, or if a block has an image that should be converted, this final pass through the AMP library will help to catch that.

 Check the option for running the full page through the libraryMake sure to check the option to run the full page through the AMP library

Analytics and ads

If you’re using Google Analytics, the AMP config page lets you enter your analytics ID so that basic Google Analytics tracking can be added to your AMP pages. The AMP specification also provides an AMP Pixel component that can be used for analytics in a way similar to how image tracking pixels work. At present, you can set up one AMP Pixel tracker by entering the domain name and URL path for the tracker. The random number tracking component is there as an example to see how this sort of tracking works. More robust AMP pixel tracking and additional analytics options may be available in the future.

Options on the AMP configuration page for ads ands analyticsThe AMP configuration page offers options to configure ads and analytics for your AMP pages

You can also enter account information for Adsense and Double Click ad accounts on the AMP config page. Once you do so, if you return to the block layout page for your AMP theme, you can place ad blocks for those networks. In Drupal 7, you are currently limited to four ad blocks for each; Drupal 8 does not have a limit on the number of ad blocks. When you place each ad block, you’ll also need to enter the slot ID from your ad network of choice for that particular ad.

View AMP pages

Congratulations! Your site can now display AMP pages! If you are editing an item where its content type has an AMP view mode enabled, you will then have an option to save and view the AMP page. You can also add ‘?amp’ to the end of the URL for the page. If the URL for the page already has a query string, you can add ‘&amp’ to the end of the existing URL. Voilà! You can now see how your AMP page looks and decide if you want to make further changes.

If some of your content appears to be missing, the AMP library validator may have removed it from the final markup. All of your original content remains within your site: it just might not show up on an AMP page. To see what actions the validator has taken, add ‘&warnfix’ to the end of the page’s URL; warning messages will then display regarding any fixes the AMP library made in order for the page to validate as AMP HTML. There is also an option on the main AMP config page to show warning messages on all AMP pages.

You can also debug your AMP pages with in-browser developer tools like Chrome Dev Tools that have a console tab. The AMP JS validator shows error messages in the console tab that can help you determine if you need to address  a problem in order for your page to validate as AMP.

Our goal is for you to have flexibility and control with how your AMP pages display. That does mean a little work to get AMP set up on a Drupal site, but we think that’s time well spent. We want your AMP pages to look just the way you want. AMP pages can be beautiful as well as fast!

Why you should try out AMP

Now that you have AMP all set up, let’s talk about why it’s worth the effort.

The web could definitely use a jump start. Too many sites get bogged down with ads, trackers and other JS. AMP offers one way to help alleviate that pain. By clamping restrictions on sites and focusing strictly on the mobile web, AMP offers impressive results. Valid AMP pages with proper schema data get cached in Google’s CDN, and furthermore can be preloaded before you even get to the page. The end result feels like magic: click a link to an AMP page, and it appears before you in a flash. Some tests have shown AMP pages rendering four times faster than equivalent non-AMP pages, while using ten times less data. Those are pretty exciting results!

Google has rolled out carousels of AMP articles in their search results, and Twitter supports AMP now as well. I’d expect we’ll see more and more places that support AMP. That’s one of the big benefits of AMP being an open source project: anybody can create an implementation to show the AMP versions of pages.

As more sites and services make use of AMP pages, creating AMP versions of your content will be more and more key. Yet despite the opportunities AMP offers, I have heard some concerns about AMP, and I wanted to discuss them.

Isn’t this like m.example.com sites with separate content for mobile? Thankfully, with the solution we’ve worked on for Drupal, you don’t need to create two entirely different sites nor do you need to keep two sets of content in sync. You can simply provide a way for the content in your current site to be transformed into AMP HTML. That gives you the benefits of AMP’s speed without too much hassle. This also doesn’t rely on browser sniffing, like m. sites did. You don’t need need to detect if the URL request comes from a mobile device, which could be a huge pain. The site linking to yours determines whether they should provide a link to the AMP or non-AMP page.

Is AMP too prescriptive in how it tackles site speed? Tim Kadlec asks that question and more in his proposal to create Content Performance Policies as an alternative to AMP. CPP could be a standardized way to say which performance standards your site adheres to, and in theory a browser could enforce adherence to these standards. Tim speculates that AMP could end up being an implementation framework to adhere to a particular CPP standard.

Can’t sites just use good practices and be fast without AMP? I think it’s great to see all the energy and competition around ways to make sites faster. Front-end performance is something I’m passionate about because it’s one more way to make the web available to all, not just those with fast devices and unlimited data. Learning how browsers work can help you to better structure your HTML, CSS and JS, fonts and images in ways that make sites speedy. There’s nothing stopping anybody from using that knowledge to make a very fast site without using AMP, a fact Paul Bakaus from the AMP project acknowledged in “Life After AMP” and in this video about AMP.

That said, knowing performance best practices and putting them in place on media-rich publishing sites is another matter. Digital publishers are under a lot of pressure, and business needs often result in ads and analytics that serve business goals, but can result in slower page loads and sluggish scrolling. Even with solid work on front-end performance optimizations, sometimes there’s only so much you can do to speed up a site.

While in the future Content Performance Policies might encourage publishers to make fast sites on their own, right now publishers can get a super fast mobile site with AMP and see firsthand the results of improving user experience with that speed. AMP forces a site to adhere to some tight limits, putting the most problematic items for performance either off limits or in a controlled sandbox. I’ve been super impressed when I’ve seen real AMP pages in action through Google AMP article carousels. I think if publishers give this a try, they’ll be impressed too. There are AMP components for analytics, so publishers can get some real world data on how well this works.

My bet is that when somebody encounters an AMP page in the wild, they’ll be wowed by the speed, and they’ll be more likely to read the article and share it. If publishers see that engagement in their analytics, that will be real world tangible evidence of the importance of front-end performance on their own sites.

With that sort of data, publishers might decide to be more selective about the JS, trackers and other items that can slow down their main site. Maybe if Content Performance Policies become more than just a proposal, publishers will rework their entire sites to adhere to those emerging standards. Perhaps they set performance budgets for their sites as a whole. Those would all be good things.

No matter the size of your site, consider giving AMP a try. With the Drupal module and theme, as well as the AMP PHP library, there’s a good way to try out AMP with your site. With a little configuration and some CSS, you can have a fast mobile site that matches your branding. You can then test the metrics for visits to AMP pages versus non-AMP pages. You might just find that front-end performance could be a key feature to further pursue. So give it a shot!

Want to learn more about AMP and Drupal? Matthew Tift, Karen Stevenson and I will be presenting a session at DrupalCon New Orleans, “AMPing up Drupal.” We hope to see you there!

And with that, I’ll speed you on your way.

Photo by Anton Pinchuk, used under Creative Commons license.

Categories: Drupal Universe

State of Drupal presentation (February 2016)

Thu, 2016-03-24 13:14

Dries Buytaert (via DrupalFire)

I was excited to travel to India a few months ago for DrupalCon, an area where we have a really big opportunity for the growth of Drupal. In keeping with tradition, here are the slides and video from my keynote presentation. You can watch the recording of my keynote (starting at 20:15) or download a copy of my slides (PDF, 158 MB).

The main areas of focus for the talk included Drupal's rapid growth and progress in India, key technology trends driving the future of the web, and how Drupal is responding to these trends. As a call-to-action, I encouraged Drupalists in India to form grassroots communities locally, to become a part of the larger Drupal community conversation, and to port modules from Drupal 7 to Drupal 8 to accelerate its adoption.

Have a look and as always, feel free to leave your thoughts in the comments!

Categories: Drupal Universe

Connecting Design Research to Your Sketches

Wed, 2016-03-23 15:37

Lullabot (via DrupalFire)

When you are able to easily communicate how a design idea is directly inspired by your design research, you'll know that you are on the path towards creating a truly meaningful user experience. But creating meaningful experiences is not easy, and the difficulty arises in the awkward transition from conducting design research to sketching ideas.

The design research phase usually leaves us with many "bits" of data, such as what our audience values, what problems they are trying to solve, organizational goals from our client, or an opportunity to create more business value than a competitor. Sketching is a sacred opportunity in the design process where our brain can more easily make connections between disparate ideas by thinking visually and spatially. If we're going to find meaningful connections between research and our design work, sketching is the time to do it. Great designers know that the true beauty of a successful visual design is born through it's strength in concept, which is best considered separately from other layers of the design process (e.g., decisions on hierarchy, styles).

If we do not successfully connect our research to our sketches, the negative impact will be felt through the entire life of the project and beyond, even into future sales cycles. If we complete our visual designs and can't make connections back to the research, we're reinforcing the lack of value in research itself, creating a reputation for research as a process where we generate a lot of data that we don't use. We create a cycle where research is difficult to sell, because we are not regularly proving its value and ultimately, producing meaningful work is very difficult. At Lullabot, our hope is to break this cycle that is impacting the larger design services community and help research to be a lean, invaluable component to creating great work.

So, how do we learn to better connect the data from our research to the ideas on our sketchpads? Here is the key:

Create a short, focused list of research highlights that are only relevant to the user story you are sketching

Better connecting design research to our sketches begins with reducing our project-wide summary of research highlights (commonly referred to as “brief”) to a more focused list of key things that are only relevant to the user story we're designing for at this moment—our team calls this a user story brief.

The project-wide research brief is very useful for sharing with the larger product team to give insight into the design process (clients, developers, project manager, etc). But even a lean process can produce pretty big pile of research findings. When we begin the process of sketching ideas, we focus on one user story at a time. A user story is a high-level user flow that may involve multiple tasks or pages (e.g. sign up for an event, make a donation, learn how to make sweet potato brownies). If we're working on a site that's more content-driven and we understand the basic information architecture up front, we may sketch for particular page types (e.g. Article, Our Work, Contact). In any case, the general idea is that we're working to simplify that original project-wide research brief to focus on only highlighting research that is relevant to what we're sketching right now.

At Lullabot, we typically have a bucket of "go to" research highlights that we reach for to help form our user story brief before we begin sketching. Here are a few examples of those key components:

Project Vision Statement

A single sentence to focus the entire team on a common, meaningful goal for the project. It gives us a one-liner that serves as a star to sail our ship by. When ideas are being evaluated, disagreements arise, or compromises have to be made, it gives us one fundamental we can all agree on and evaluate against. Below are a few examples:

  • Connect and engage employees wherever they are with timely, relevant content.
  • Connect, inspire, and empower advocates for music making and education.

So, the first step when evaluating ideas for new content or experiences is to answer the questions above...how does this idea connect and engage employees wherever they are with timely, relevant content? Or how does this idea connect, inspire, and empower advocates for music making and education?

Design Principles

Guiding design principles are informed by all areas of the research process. We like to write principles with a simple, memorable, title and a description. We typically leave the description out when preparing for sketching and simply write the principles near our workstation, along with the project vision statement. Here are a select few principles we've written for our projects:

  • Relevance over breadth
    This principle makes us constantly ask “Does this audience type care about that component, that piece of content, that link?” as we’re evaluating ideas and designs.
  • Care for the newcomer
    Look for creative ways to provide tailored experiences for on-boarding employees. These ways may include prioritization decisions within the default designs, but also technical approaches for providing specialized experiences for the on-boarding process.
  • Show and tell stories
    Whenever and wherever possible, tell users about the Spredfast platform and products by telling real world stories, in the words of actual Spredfast customers. Find ways to show the value of something rather simply describing it.

Project Goals

Before sketching, re-read all project goals (e.g. business goals, marketing goals, design goals, technical goals). Are there any you'd like to keep front-of-mind for this user story design? Here are few examples of goals:

  • Increase donations significantly. An increase in donations would be one indication that the site is doing a better job of telling the story of the impact of the NAMM Foundation’s work. A site that truly “inspires and empowers” can play a role in increasing the number and significance of donors.
  • Increased site speed, particularly on mobile. Success: A 25-50% decrease in load time for the home page on mobile (the home page currently loads in 11.91 seconds)
  • Create a design that will appear on the short-list of best-designed entertainment and news web sites.
    Success: Submit Grammy.com as an entry to multiple awards organizations and receive a press-worthy award.

Persona Needs and Values

What personas are important to keep in mind for this user story? What are their common pain points? What are their key questions when they arrive at this page? What do they value? Below is an example of how we keep our personas text-based (no fake profile pictures) and simple.

Bob Bot the Lullabot:
Bob is a developer at Lullabot. He thinks that working for Lullabot is pretty awesome and loves the idea of showing off his company culture and work to the development community. Bob is fascinated by new delightful experiences on the web and appreciates design ingenuity.Bob Bot likes apps and websites that are intuitive, easy to use, clean & minimal with no distractions from the overall task. Apps and websites used regularly: Github, Reddit, Facebook, Twitter, Yammer, Amazon, Kindle, Readability, Unread, Feedly, New York Times, Google Inbox, Pocket, phpStorm

Visits Lullabot.com to: Review Lullabot.com redesign and share with dev community, read or post articles, listen to podcasts created by fellow bots, review his own bio on the who we are page, and read the new case study of a project he worked on. Main aspects that drew Bob Bot to work for Lullabot: Having great co-workers that are knowledgeable, passionate, talented and fun and having an outstanding reputation in the Drupal/web development community

Presentation Model

"Presentation model" is a fancy term for "here are ways we can present content on the page". For example, if we're redesigning a donation page, it may be clear to us that having a 1) donation form and 2) privacy policy links, etc are definitely "things that needs to be on this page".

Market research takeaways and other relevant research

Are there any notes you have on competitors, inspiration sites, Nielsen Norman reports, etc. that would be helpful to reference when sketching this story? Other ideas include: general design concerns or technical constraints presented by the client, google analytics highlights and key adjectives that represent the brand (Bold, Risky, Elegant).

In summary, use the research highlight ideas mentioned above to create a simple brief that is specific to the user story you are sketching. The more simple your brief, the more likely you will be to connect your research to your sketch. Every user story brief will have a different structure because every sketch involves a unique combination of research "bits" that are relevant to only the specific problem you're solving. The key is to keep the user story brief as short and focused as possible. The more simple our list, the more likely we are to truly make strong connections from our research to our sketchpads.

Bring your research highlights into the same physical space as your sketchpad

Andrew Smyk with Adobe writes about a creative way that he creates new connections when sketching:

"One of my favorite techniques is to photocopy some of my sketches, cut them up into the base components, as described in Brad Frost’s Atomic Design, and then begin fleshing out the design concept by grouping and reshuffling components. I find that by physically moving the pieces of paper around, it allows me to identify patterns and think about how the user will interact with the design solution and interpret my messaging."

Let's apply the same idea of components and spatial thinking to our design research data. Chose a select few research highlights and write each highlight on a single notecard. Place those cards near your sketchpad while designing. Notecards are a designer’s best friend! The small space on a notecard helps to focus you on singular ideas. In order to more easily connect our research data to our ideas, we reduce our research data to singular components and bring them into the same physical space as our sketches. Now we can physically move the highlights around and make new connections with our sketched components, allowing you to reap the benefits of spatial thinking and learning. When you present your sketches, you should be able to easily communicate the research that inspired the idea by simply reading each notecard that is sitting next to your sketched component.



  • Research + sketches = more meaningful work, higher chance of success for the project
  • Before beginning to sketch, reduce your project-wide research findings to only the key highlights that are relevant to the user story or page you are sketching. The more simple the highlights list, the easier it will be to truly connect them to your ideas and communicate those connections to your team.
  • Try writing those research "bits" on individual notecards and placing them next to your sketchpad to reap the benefits of spatial thinking and learning.
Categories: Drupal Universe

Drupal Association Board - An Open Farewell.

Wed, 2016-03-23 13:42

Matthew Saunders (via DrupalFire)


In November of 2013 I cycled onto the Drupal Association Board. I was excited to be taking part in an organization that had supported the way I had chosen to make my living over the last few years. I knew many of the other board members quite well. The term was for one year - which seemed very short to me. I had worked with other Non-profits, on and with other Non-profit boards, and knew that one year was barely enough time to get up to speed. Still, there was opportunities for me to help steer the organization. Early on, I was involved in reworking the Association's Vision, Mission, and Values. Later, I helped update the bylaws to increase elected board member's terms to two years and at the same time, shifted the dates which elections were occurring. That is the reason my one year term has become closer to two and half. I also worked with the board to establish term limits on appointment members. There are lots of other things that I've been involved with over the last two and half years, but these shine out to me.

This year my term was due for expiration. I had hoped to extend my work with the Association by another two years. Let me share some numbers with you.

drupaldrupal association election 2016thank-you

Categories: Drupal Universe

Always Improve: Iterating on company values

Tue, 2016-03-22 19:54

Four Kitchens (via DrupalFire)

Four Kitchens wants to change the world – these the company values that are going to help make that happen.

Categories: Drupal Universe

How should you decouple Drupal?

Tue, 2016-03-22 10:03

Dries Buytaert (via DrupalFire)

With RESTful web services in Drupal 8 core, Drupal can function as an API-first back end serving browser applications, native applications on mobile devices, in-store displays, even in-flight entertainment systems (Lufthansa is doing so in Drupal 8!), and much more. When building a new website or web application in 2016, you may ask yourself: how should I decouple Drupal? Do I build my website with Drupal's built-in templating layer or do I use a JavaScript framework? Do I need Node.js?

There is a lot of hype around decoupled architectures, so before embarking on a project, it is important to make a balanced analysis. Your choice of architecture has implications on your budget, your team, time to launch, the flexibility for content creators, the ongoing maintenance of your website, and more. In this blog post, I'd like to share a flowchart that can help you decide when to use what technology.

Decoupled decision flowchart

This flowchart shows three things:

First, using coupled Drupal is a perfectly valid option for those who don't need extensive client-side rendering and state management. In this case, you would use Drupal's built-in Twig templating system rather than heavily relying on a JavaScript framework. You would use jQuery to take advantage of limited JavaScript where necessary. Also, with BigPipe in Drupal 8.1, certain use cases that typically needed asynchronous JavaScript can now be done in PHP without slowing down the page (i.e. communication with an external web service delaying the display of user-specific real-time data). The advantage of this approach is that content marketers are not blocked by front-end developers as they assemble their user experiences, thus shortening time to market and reducing investment in ongoing developer support.

Second, if you want all of the benefits of a JavaScript framework without completely bypassing Drupal's HTML generation and all that you get with it, I recommend using progressively decoupled Drupal. With progressive decoupling, you start with Drupal's HTML output, and then use a JavaScript framework to add client-side interactivity on the client side. One of the most visited sites in the world, The Weather Channel (100 million unique visitors per month), does precisely this with Angular 1 layered on top of Drupal 7. In this case, you can enjoy the benefits of having a “decoupled" team made up of both Drupal and JavaScript developers progressing at their own velocities. JavaScript developers can build richly interactive experiences while leaving content marketers free to assemble those experiences without needing a developer's involvement.

Third, whereas fully decoupled Drupal makes a lot of sense when building native applications, for most websites, the leap to fully decoupling is not strictly necessary, though a growing number of people prefer using JavaScript these days. Advantages include some level of independence on the underlying CMS, the ability to tap into a rich toolset around JavaScript (e.g. Babel, Webpack, etc.) and a community of JavaScript front-end professionals. But if you are using a universal JavaScript approach with Drupal, it's also important to consider the drawbacks: you need to ask yourself if you're ready to add more complexity to your technology stack and possibly forgo functionality provided by a more integrated content delivery system, such as layout and display management, user interface localization, and more. Losing that functionality can be costly, increase your dependence on a developer team, and hinder the end-to-end content assembly experience your marketing team expects, among other things.

It's worth noting that over time we are likely to see better integrations between Drupal and the different JavaScript frameworks (e.g. Drupal modules that export their configuration, and SDKs for different JavaScript frameworks that use that configuration on the client-side). When those integrations mature, I expect more people will move towards fully decoupled Drupal.

To be performant, fully decoupled websites using JavaScript employ Node.js on the server to improve initial performance, but in the case of Drupal this is not necessary, as Drupal can do the server-side pre-rendering for you. Many JavaScript developers opt to use Node.js for the convenience of shared rendering across server and client rather than for the specific things that Node.js excels in, like real-time push, concurrent connections, and bidirectional client-server communication. In other words, most Drupal websites don't need Node.js.

Decoupled delivery architectures

In practice, I believe many organizations want to use all of these content delivery options. In certain cases, you want to let your content management system render the experience so you can take full advantage of its features with minimal or no development effort (coupled architecture). But when you need to build a website that needs a much more interactive experience or that integrates with unique devices (i.e. on in-store touch screens), you should be able to use that same content management system's content API (decoupled architecture). Fortunately, Drupal allows you to use either. The beauty of choosing from the spectrum of fully decoupled Drupal, progressively decoupled Drupal, and coupled Drupal is that you can do what makes the most sense in each situation.

Special thanks to Preston So, Alex Bronstein and Wim Leers for contributions to this blog post. We created at least 10 versions of this flowchart before settling on this one.

Categories: Drupal Universe

Installing and Configuring Redis for Drupal 7, and other Memcached Alternatives

Tue, 2016-03-22 03:15

2bits (via DrupalFire)

For years, we have been using and recommending memcached for Drupal sites as its caching layer, and we wrote several articles on it, for example: configuring Drupal with multiple bins in memcached.

Memcached has the advantage of replacing core caching (which uses the database) with memory caching. It still allows modules that have hook_boot() and hook_exit() to work, unlike external cache layers such as Varnish.

However, memcached has its limitations: It is by definition transient, so rebooting wipes out the cache, and the server can suffer if it has high traffic. It is also entirely memory resident, so to cache more items you need more RAM, which is not suitable for small servers.

For Drupal 7, there is a solution that does avoids this first limitation: Redis. It provides persistence, but not the second.

The following is a detailed guide to get Redis installed and configured for your server. It assumes that you are an Ubuntu Server 14.04, or the equivalent Debian release.

Installing Redis

First, download the Drupal redis module, which should go to sites/all/modules/contrib. You can do that in many ways, here is how you would use Drush for that:

drush @live dl redis

You do not need to enable any Redis modules in Drupal.

Then, install the Redis Server itself. On Debian/Ubuntu you can do the following. On CentOS/RedHat, you should use yum.

aptitude install redis-server

Then, install PHP's Redis integration. Once you do that, you do not need to compile from source, or anything like that, as mentioned in Redis README.txt file.

aptitude install php5-redis

Restart PHP, so it loads the Redis integration layer.
This assumes you are using PHP FPM:

service php5-fpm restart

If you are using PHP as an Apache module, then you need to restart it as follows:

service apache2 restart
Configuring Redis

Then in your settings.php file, you should replace the section for memcache which would be as follows:

$conf['cache_backends'][] = './sites/all/modules/contrib/memcache/memcache.inc';
$conf['cache_default_class'] = 'MemCacheDrupal';
$conf['memcache_servers'] = array('' => 'default');
$conf['memcache_key_prefix'] = 'site1';

And replace it with the following configuration lines:

// Redis settings
$conf['redis_client_interface'] = 'PhpRedis';
$conf['redis_client_host'] = '';
$conf['lock_inc'] = 'sites/all/modules/contrib/redis/redis.lock.inc';
$conf['path_inc'] = 'sites/all/modules/contrib/redis/redis.path.inc';
$conf['cache_backends'][] = 'sites/all/modules/contrib/redis/redis.autoload.inc';
$conf['cache_default_class'] = 'Redis_Cache';
// For multisite, you must use a unique prefix for each site
$conf['cache_prefix'] = 'site1';
Cleaning Up

Once you do that, caching will start using redis. Memcached is not needed, so you should stop the daemon:

service memcached stop

And you should purge memcached as well:

aptitude purge memcached

And that is all there is to it.

Changing Redis Configuration

You can then review the /etc/redis/redis.conf file to see if you should tweak parameters more, such as changing maxmemory to limit it to a certain amount, as follows:

maxmemory 256mb

More below on this specific value.

Checking That Redis Is Working

To check that Redis is working, you can inspect that keys are being cached. For this, you can use the redis-cli tool. This tool can be used interactively, as in, you get a prompt and type commands in it, and results are returned. Or you can use the specific command as an argument to redis-cli.

For example, this command filters on a specific cache bin, the cache_bootstrap one:

$ redis-cli> keys *cache_boot*

Or you can type it as:

$ redis-cli keys "*cache_boot*"

In either case, if Drupal is caching correctly, you should see output like this:

1) "site1:cache_bootstrap:lookup_cache"
2) "site2:cache_bootstrap:system_list"
3) "site3:cache_bootstrap:system_list"
4) "site3:cache_bootstrap:hook_info"
5) "site2:cache_bootstrap:variables"

As you can see, the key structure is simple, it is composed of the following components, separated by a colon:

  • Cache Prefix
    This is the site name in a multi site environment.
  • Cache Bin
    This is the cache table name when using the default database caching in Drupal.
  • Cache Key
    This is the unique name for the cached item. For cached pages, the URL is used, with the protocol (http or https) and the host/domain name.

You can also filter by site, using the cache_prefix:

$ redis-cli keys "*site1:cache_page*"

The output will be something like this:

1) "site1:cache_page:http://example.com/node/1"
2) "site1:cache_page:http://example.com/contact_us"

You can also check how many items are cached in the database:

$ redis-cli dbsize

The output will be the number of items:

(integer) 20344
Flushing The Cache

If you need to clear the cache, you can do:

$ redis-cli flushall
Checking Time To Live (TTL) For A Key

You can also check how long does a specific item stay in cache, in seconds remaining:

$ redis-cli ttl site1:cache_page:http://example.com/

The output will be the number of seconds:

(integer) 586
Getting Redis Info

You can get a lot of statistics and other information about how Redis is doing, by using the info command:

$ redis-cli info

You can check the full documentation for the info command.

But here is one of the important values to keep an eye on is used_memory_peak_human, which tells you the maximum memory that was used given your site's specifics, such as the number of items cached, the rate of caching, the size of each item, ...etc.


You can use that value to tune the maxmemory parameter, as above.

You can decrease the Minimum Cache Lifetime under /admin/config/development/performance to make the available memory fit that number, or the other way around: you can allocate more memory to fit more.

Monitoring Redis Operations In Real Time

And finally, here is a command that would show you all the operations that are being done on Redis in real time. Do not try this on a high traffic site!

$ redis-cli monitor
Performance Results

Redis performance as a page cache for Drupal is quite good, with Time To First Byte (TTFB) is ~ 95 to 105 milliseconds.

Alternatives To Redis and Memcached

We did fairly extensive research for Redis and Memcached alternatives with the following criteria:

  • Compatible With Redis or Memcached Protocol
    We wanted to use the same PHP extension and Drupal Redis (or Memcached) modules, and not have to write and test yet another caching module.
  • Non-Memory Resident Storage
    We want to reduce the memory foot print of Redis/Memcached, because they both store the entire key/value combinations in memory. But still wanted to get acceptable performance.

The following products all claim to meet the above criteria, but none of them worked for us. They were tested on Ubuntu LTS 14.04 64-bit:


Using MongoDB article for more details.


MemcacheDB is a Memcached compatible server which used the excellent Berkeley DB database for storage.

This MemcacheDB presentation explains what it does in detail.

It has an Ubuntu package right in the repository, so no need to compile from source, or manually configure it. It works flawlessly. The -N option enable the DB_TXN_NOSYNC option, which means writes to the database are asynchronous, providing a huge performance improvement.

Configuration in Drupal's settings.php is very easy: it is exactly like Memcached, with only the port number changing, from 11211 to 21201.

Alas, all is not rosy: it is not really a cache layer, since it does not expire keys/values based on time, like Memcached and Redis does.

Redis NDS

Redis-NDS is a fork of Redis 2.6, patched for NDS (Naive Disk Store).

It does compile and run, but when the line: 'nds yes' is added to the configuration file, it is rejected as an invalid value. Looking briefly in the source, we also tried 'nds_enabled yes', but that was rejected as well. So we could not get it to run in NDS mode.


ARDB is another NoSQL database that aims to be Redis protocol compatible.

We compiled this with three different storage engines: The Facebook RocksDB did not compile to begin with. Google's LevelDB compiled cleanly, and so did WiredTiger. But when trying to connect Drupal to it, Drupal hanged and never came back with both engines.


SSDB is also another NoSQL database that tries to be Redis protocol compatible.

It compiled cleanly, but had the same symptom as ARDB: Drupal hangs and never receives back a reply from SSDB.

There are a couple of sandbox projects, here and here, that aim for native integration, but no code has been committed so far in two years.

If you were able to get any of the above, or another Redis/Memcached compatible caching engine working, please post a comment below.




Categories: Drupal Universe

MongoDB as a caching solution for Drupal 7

Tue, 2016-03-22 03:05

2bits (via DrupalFire)

MongoDB is a NoSQL database that has Drupal integration for various scenarios.

One of these scenarios is using MongoDB as the caching layer for Drupal.

This article describes what is needed to get MongoDB working as a caching layer for your Drupal site. We assume that you have an Ubuntu Server LTS 14.04 or similar Debian derived distro.

Download The Drupal Module

First, download the MongoDB Drupal module. You do not need to enable any MongoDB modules.

drush @live dl mongodb
Install MongoDB Server, Tools and PHP Integration

Then install MongoDB, and PHP's MongoDB integration. Note that 'mongodb' is a virtual package that installs the mongodb-server package as well as other client tools and utilities:

aptitude install php5-mongo mongodb
Restart PHP

Restart PHP, so that MongoDB integration takes effect:

service php5-fpm restart
Configure Drupal With MongoDB

Now, edit your settings.php file, to add the following:

$conf['mongodb_connections']['default']['host'] = 'mongodb://';
$conf['mongodb_connections']['default']['db'] = 'site1';
$conf['cache_backends'][] = 'sites/all/modules/contrib/mongodb/mongodb_cache/mongodb_cache.inc';
$conf['cache_default_class'] = 'DrupalMongoDBCache';

Note, that if you have multisite, then using a different 'db' for different sites will prevent cache collision.

Monitoring MongoDB

You can monitor MongoDB using the following commands.

mongotop -v
mongostat 15
Tuning MongoDB

Turn off MongoDB's journaling, since we are using MongoDB for transient cache data that can be recreated from Drupal.

Edit the file /etc/mongodb.conf and change journal= to false.

Performance Results

Quick testing on a live site showed that MongoDB performance is acceptable, but not spectacular. That is specially true when compared to other memory resident caching, such as Memcached or Redis.

For example, on the same site and server, with Redis, Time To First Byte (TTFB) is ~ 95 to 105 milliseconds. With MongoDB it is ~ 200, but also goes up to ~350 milliseconds.

Still, MongoDB can be a solution in memory constrained environments, such as smallish VPS's.



Categories: Drupal Universe

Get a decorator for your Drupal home

Wed, 2016-03-16 07:01

Lullabot (via DrupalFire)

Design patterns

Software design patterns are general and reusable software design solutions to a defined problem. They were popularized in 1994 by the “Gang of Four” after their book Design Patterns: Elements of Reusable Object-Oriented Software.

These generic solutions are not snippets of code, ready to be dropped in your project, nor a library that can be imported and reused. Instead they are a templated solution to the common software challenges in your project. Design patterns can also be seen as best practises when encountering an identified problem.

With Drupal 8’s leap into modern PHP, design patterns are going to be more and more relevant to us. The change from (mostly) procedural code to (a vast majority of) object oriented code is going to take the Drupal community at large through a journey of adaptation to the new programming paradigm. Quoting the aforementioned Design Patterns: Elements of Reusable Object-Oriented Software:

[…] Yet experienced object-oriented designers do make good designs. Meanwhile new designers are overwhelmed by the options available and tend to fall back on non-object-oriented techniques they've used before. It takes a long time for novices to learn what good object-oriented design is all about. Experienced designers evidently know something inexperienced ones don't. What is it?

Even if you don’t know what they are, you have probably been using design patterns by appealing to common sense. When you learn what they are you’ll be thinking “Oh! So that thing that I have been doing for a while is called an adapter!”. Having a label and knowing the correct definition will help you communicate better.

The decorator

Although there are many design patterns you can learn, today I want to focus in one of my favorites: the decorator.

The decorator pattern allows you to do unobtrusive behavior inheritance. We can have many of the benefits of inheritance and polymorphism without creating a new branch in the class’ inheritance tree. That sounds like a mouth full of words, but this concept is especially interesting in the Drupal galaxy.

In Drupal, when you are writing your code, you cannot possibly know what other modules your code will run with. Imagine that you are developing a feature that enhances the entity.manager service, and you decide to swap core’s entity.manager service by your enhanced version. Now when Drupal uses the manager, it will execute your manager, which extends core’s manager and overrides some methods to add your improvements. The problem arises when there is another module that does the same thing. In that situation either you are replacing that module’s spiced entity manager or that module is replacing your improved alternative. There is no way to get both improvements at the same time.

This is the type of situations where the decorator pattern comes handy. You cannot have this new module inheriting from your manager, because you don’t know if all site builders want both modules enabled at the same time. Besides, there could be an unknown number of modules –even ones that are not written yet– that may create the conflict again and again.

Using the decorator

In order to create our decorator we’ll make use of the interface of the object we want to decorate. In this case it is EntityManagerInterface. The other key component is the object that we are decorating, let’s call it the subject. In this case our subject will be the existing object in the entity.manager service.

Take for instance a decorator that does some logging every time the getStorage() method is invoked, for debugging purposes. To create a decorator you need to create a pristine class that implements the interface, and receives the subject.

class DebuggableEntityManager implements EntityManagerInterface {

protected $subject;

public function __construct(EntityManagerInterface $subject) {

$this->subject = $subject;



The key concept for a decorator is that we are going to delegate all method calls to the subject, except the ones we want to override.

class DebuggableEntityManager implements EntityManagerInterface {

protected $subject;

// ...

public function getViewModeOptions($entity_type_id) {

return $this->subject->getViewModeOptions($entity_type_id);


// …

public function getStorage($entity_type) {

// We want to add our custom code here and then call the “parent” method.


// Now we use the subject to get the actual storage.

return $this->subject->getStorage($entity_type);



As you have probably guessed, the subject can be the default entity manager, that other module’s spiced entity manager, etc. In general you’ll take whatever the entity.manager service holds. You can use any object that implements the EntityManagerInterface.

Another nice feature is that you can decorate an already decorated object. That allows you to have multiple decorators adding different features without changing the inheritance. You can now have a decorator that adds logging to every method the entity manager executes, on top of a decorator that adds extra definitions when calling getFieldDefinitions(), on top of …

I like the coffee making example in the decorator pattern entry in Wikipedia, even if it’s written in Java instead of PHP. It’s a simple example of the use of decorators and it reminds me of delicious coffee.

Benefits and downsides

One of the downsides of using the decorator pattern is that you can only act on public methods. Since you are –intentionally– not extending the class of the decorated object, you don’t have access to any private or protected properties and methods. There are a couple of situations similar to this one where the decorator pattern may not be the best match.

The business logic you want to override is contained in a protected method, and that method is reused in several places. In this case you would end up overriding all the public methods where that protected one is called.

You are overriding a public method that is executed in other public methods. In such scenario you would not want to delegate the execution to the subject, because in that delegation your overridden public method would be missed.

If you don’t find yourself in one of those situations, you’ll discover that the decorator has other additional benefits:

  • It favors the single responsibility principle.
  • It allows you to do the decoration during run-time, whereas subclassing can only be done in compile-time.
  • Since the decorator pattern is one of the commonly known design patterns, you will not have to thoroughly describe your implementation approach during the daily scrum. Instead you can be more precise and just say “I’m going to solve the problem using the decorator pattern. Tada!”.

Write better designs

Design patterns are a great way to solve many complex technical problems. They are a heavily tested and discussed topic with lots of examples and documentation in many programming languages. That does not imply that they are your new golden hammer, but a very solid source of inspiration.

In particular, the decorator pattern allows you to add features to an object at run-time while maintaining the object’s interface, thus making it compatible with the rest of the code without a single change.

Categories: Drupal Universe

A "MAP" for accelerating Drupal 8 adoption

Tue, 2016-03-15 21:02

Dries Buytaert (via DrupalFire)

Contributed modules in Drupal deliver the functionality and innovation proprietary content management solutions simply can't match. With every new version of Drupal comes the need to quickly move modules forward from the previous version. For users of Drupal, it's crucial to know they can depend on the availability of modules when considering a new Drupal 8 project or migrating from a previous version.

I'm pleased that many agencies and customers who use Drupal are donating time and attention to maintaining Drupal's module repository and ensuring their contributed modules are upgraded. I believe it's the responsibility of Drupal companies to give back to the community.

I'm proud that Acquia leads by example. It was with great pride that Acquia created a Drupal 8 Module Acceleration Program, or MAP. Led by Acquia's John Kennedy, MAP brings financial, technical and project management assistance to Drupal module maintainers. Acquia kicked off MAP in mid-October and to date we have helped complete production-ready versions of 34 modules. And it is not just any modules; we've been focused on those modules that provide critical pieces of functionality used by most Drupal sites.

When MAP was formed Acquia allocated $500,000 to fund non-Acquia maintainers in the community. In addition, we have so far invested more than 2,500 hours of our own developers' time to support the effort (the equivalent of three full-time developers).

What is impressive to me about MAP is both the focus on mission-critical modules that benefit a huge number of users, as well as the number of community members and agencies involved. John's team is leading a coalition of the best and brightest minds in the Drupal community to address the single biggest obstacle holding Drupal 8 adoption back.

Drupal 8 has already made a significant impact; in the 90 days following the release of Drupal 8.0.0, adoption has outpaced Drupal 7 by more than 200 percent. And as more modules get ported, I expect Drupal 8 adoption to accelerate even more.

Categories: Drupal Universe

Tracking Live Election Data

Tue, 2016-03-15 00:00

Development Seed (via DrupalFire)

Real-time data is great. Building real-time interfaces is hard.

We teamed up with the Washington Post to build tools for their live election coverage of the US primary elections. The Washington Post knew that many people would track the election on a mobile phone or tablet, often while watching another screen. Our challenge was to build a real-time data app that engages users and make it easy to track the most important information. Inspired by interactions and visual presentation from fantasy football apps, we designed tools for live election tracking that make it clear when the data is changing and provide contextual information to make these changes understandable.


Reporting live events through data

We noticed similarities between the football games were were tracking and the primaries we were building for. There is a winner. The results unfold over 2-4 hours. There are close games and blowouts. These situations can translate into interesting events during a primary race. For example, when the lead frequently flips or when a candidate outperforms expectations.

With any time based event, what piques a user’s interest isn’t necessary what happens during one point in time but how the data or information changes moment-by-moment. Sports apps address these challenges on a daily basis. We formed a small fantasy football league, to practice tracking multiple games simultaneously through apps and websites. We evaluate how these apps informed users of real-time updates. A regular NFL Sunday became our preparation for Super Tuesday. We were frustrated by the apps that made it hard to track multiple games simultaneously. We loved the apps that showed us what had happened since the last update. The best apps had a clear hierarchy of information. They showed an overview of all the games but allowed you to easily dig in and flip between games. The best apps were selective about what data to show at what level. They let you know where the ball is, how much time is left, who is in ‘the red zone’, and what games are worth watching.

We translated our findings from football tracking to election tracking. Election data can be overwhelming when results come in all at once from thousands of counties, across multiple states, for a plethora of candidates. We started with a clean interface that was selective about what data to show at the national and state level.

Highlighting New Information


To make sure users are always up to date on the most important action, just like in the fantasy football apps, we introduced a design tool to highlight counties where something meaningful was taking place. If the leading candidates are within 1% of each other, a candidate has just overtaken another candidate, or the race has been called, that county receives a highlight on the map and an annotation in the tooltip. This was a way to highlight the ‘red zone’ in an election race. It offers a clean, non-intrusive way to help the Post’s readers make a little more sense out of the results coming in and to not miss any of the action.

Context layers

The main map view shows who is winning in each county. This has the advantage of being extremely easy to understand and track over time. The disadvantage of this kind of map is that it can misrepresent the importance of large, rural counties with few votes. To compensate for this we added a population layer to give users more context for results. We used a light population stippling to give users a clean visual cues of which counties would have more votes. We continuously adjusted color palette, opacity, and shade of the data layer and the population stripling to make sure this layer stood out without mudding the map. We started with more saturated colors but ended up going with much lighter tones by Super Tuesday to allow the population layer to really shine through.


With many republican candidates and a tight democratic race, precise maps and a focused narrative are more important than ever. We hope the population layer and real-time curated updates give users the right visual cues to give them a better understanding of election data coming in night by night. You can try the app tonight on the Washington Post site while you track results from Florida, Illinois, Missouri, North Carolina, and Ohio.

Categories: Drupal Universe

White House deepens its commitment to Open Source

Fri, 2016-03-11 18:09

Dries Buytaert (via DrupalFire)

Yesterday, the White House announced a plan to deepen its commitment to open source. Under this plan, new, custom-developed government software must be made available for use across other federal agencies, and a portion of all projects must be made open source and shared with the public. This plan will make it much easier to share best practices, collaborate, and save money across different government departments.

However, there are still some questions to address. In good open source style, the White House is inviting developers to comment on this policy. As the Drupal community we should take advantage and comment on GitHub within the 30-day feedback window.

The White House has a long open source history with Drupal. In October 2009, WhiteHouse.gov relaunched on Drupal and shortly thereafter started to actively contribute back to Drupal -- both were a first in the history of the White House. White House's contributions to Drupal include the "We the People" petitions platform, which was adopted by other governments and organizations around the world.

This week's policy is big news because it will push open source deeper into the roots of the U.S. government, requiring more government agencies to become active open source contributors. We'll be able to solve problems faster and, together, build better software for citizens across the U.S.

I'm excited to see how this plays out in the coming months!

Categories: Drupal Universe

Dad, you need a password manager

Fri, 2016-03-11 16:00

Four Kitchens (via DrupalFire)

Dear Dad, it’s time that we had an important talk about technology. We have to talk about passwords. As you know nearly every website asks you to create an account and each account needs a password. It is important that these passwords are secure.

Categories: Drupal Universe

DrupalBooks.com for sale

Fri, 2016-03-11 04:59

John Forsythe (via DrupalFire)

A long time ago, I was approached by a publishing company to write a book on Drupal security. That never ended up happening, but I did become a technical reviewer for someone else's book. Along the way, I picked up a domain: DrupalBooks.com. Since it's highly unlikely I'll ever get around to writing a book about Drupal, I'm putting the domain up for sale. If you're interested in acquiring DrupalBooks.com, please send me an email at john@blamcast.net.

Categories: Drupal Universe

Thanks for helping Amplify Austin

Thu, 2016-03-10 21:21

Four Kitchens (via DrupalFire)

YEEESSSSS!!!!!! I Live Here, I Give Here’s 24-hour charitable giving drive, Amplify Austin, was a huge success! Read about how much was raised and the causes dear to our Web Chefs’ hearts.

Categories: Drupal Universe

Weekly Watercooler #138

Thu, 2016-03-10 16:35

Four Kitchens (via DrupalFire)

Categories: Drupal Universe

Talk good on the Internet

Wed, 2016-03-09 20:00

Four Kitchens (via DrupalFire)

It’s often said that language is the window for our minds; a way to see the world at a distance without directly experiencing it. But how we say something is often just as important as what we’ve said. You are what you talk and, in our line of work, the language you use online is always interpreted as an extension of your brand. So learn how to talk good in this installment of Digital Diner.

Categories: Drupal Universe