CHROMATIC | Projects

Only 16% of consumer brands have a mobile strategy, so it’s no surprise that only 14% are happy with the results.

matt — Tue, 18 Jun 2013 16:51:34 +0000

Digiday

46% of shoppers reported they exclusively use their mobile device to conduct pre-purchase research for local products and services.

matt — Tue, 18 Jun 2013 16:50:35 +0000

Mobile Path-to-Purchase Study

Blacks, Hispanics, low-income Americans, high school educated are more likely to be mobile-only users.

matt — Tue, 18 Jun 2013 16:49:18 +0000

Pew Internet

55% of mobile phone owners say they use their phone to access the internet.

matt — Tue, 18 Jun 2013 16:48:32 +0000

Pew Internet

Responsive Grid Building with Sass and Zen Grids: The Tale of the Breakpoint Grid Breakdown mixin

gus — Tue, 18 Jun 2013 03:41:18 +0000

A common scenario in the world of responsive design: a grid of elements needs to have different numbers of columns depending on the screen width. This can easily be accomplished using media queries and clever selectors, but what if the same effect is needed on another list of elements? With Sass, you might create a mixin to avoid rearranging your styles or even worse, copying and pasting those rules.

Let's take it to the next level. Other grids with different selectors need different numbers of columns across different breakpoints. What then? Create another, almost identical mixin? No! You're copying and pasting again! Instead, create one mixin that can be passed a few variables and sit back while it does all the work for you. How? Keep reading!

Before we get started, it's worth mentioning that this specific example is tailored to Sass and Zen Grids. If you are not using Sass, we'd highly recommend it. It just might change your life. As for Zen Grids, we've been using it a lot lately. If you're using a different responsive grid framework, that's cool, but you'll need to adapt small portions of the final mixin.

For those who are skimming: jump to the meat and potatoes of the article.

Creating a breakpoint mixin

If you aren't already doing something similar, this is a slick strategy for styling one element across multiple breakpoints.

First, create a simple mixin like so:

@mixin breakpoint($breakpoint-size) {
  @media all and (min-width: $breakpoint-size) {
    @content;
  }
}

You can pass that mixin pixel values, but if you're using it a lot (you will be), you'll probably want to define some variables. We don't like using device-centric names for ours (they aren't future-friendly), but we're going to here to keep things easy to understand.

Maybe you define these breakpoints:

$breakpoint-mobile: 320px;
$breakpoint-tablet: 768px;
$breakpoint-desktop: 960px;

As a general strategy, we prefer to use these mixins multiple times within a given element rather than spread the same element across a few "master" media queries. Notice we used min-width in the mixin above. By listing the breakpoints from small to large, the styles become additive and will override the same rules in smaller breakpoints.

Using the mixin could look something like this:

.headline {
  // Global and mobile styles
  font-family: sans-serif;
  font-size: 1em;

  @include breakpoint($breakpoint-mobile) {
    // Styles from 480px on up. Can override those previously defined.
    font-size: 1.25em;
    font-weight: bold;
  }
  @include breakpoint($breakpoint-tablet) {
    // Styles from 768px on up. Again, can override.
    font-size: 1.5em;
  }
  @include breakpoint($breakpoint-desktop) {
    // Styles from 960px on up. Overrides everything!
    font-size: 2em;
    font-style: italic;
  }
}

Keep in mind that you might use more (or less) breakpoints in any given element. You don't have to use every breakpoint in every element - just use what you need in each one.

This example produces the following CSS:

.headline {
  font-family: sans-serif;
  font-size: 1em;
}
@media all and (min-width: 320px) {
  .headline {
    font-size: 1.25em;
    font-weight: bold;
  }
}
@media all and (min-width: 768px) {
  .headline {
    font-size: 1.5em;
  }
}
@media all and (min-width: 960px) {
  .headline {
    font-size: 2em;
    font-style: italic;
  }
}

That gets us through using a simple mixin to change styles across breakpoints. Awesome!

Dynamic grid creation with Breakpoint Grid Breakdown

Now is when things get exciting. Remember the scenario that we proposed at the beginning of the article? We need to create one mixin that can accomodate styles for different grids with different numbers of columns across different breakpoints.

Note: the most common use case for this is styling a View. When doing so, don't use the Grid format! Use "HTML list" or "Unformatted" and this mixin will build the grid for you.

Here we go (with a heavy dose of comments):

// Breakpoint Grid Breakdown
// Displays a grid of items with a dynamic column count across breakpoints.
// For use with Zen Grids and a breakpoint-oriented mixin.
// @author Gus Childs http://drupal.org/user/1468898
//
// @param list $column-counts
//   A list of how many columns should exist on the respective breakpoints.
// @param list $breakpoints
//   A list of breakpoints to be used in the 'breakpoint' mixin. Corresponds
//   directly with the $column-counts list. Defaults to those commonly used.
// @param string $selector
//   The selector of each individual grid item. Defaults to 'views-row'.
@mixin breakpoint-grid-breakdown($column-counts, $breakpoints: $breakpoint-mobile $breakpoint-tablet $breakpoint-desktop, $selector: '.views-row') {
  // The selector, such as '.views-row'.
  #{$selector} {
    // Loop through the breakpoints specified.
    @each $breakpoint in $breakpoints {
      // Which breakpoint are we currently on?
      $key: index($breakpoints, $breakpoint);
      // How many columns should exist in that breakpoint?
      $column-count: nth($column-counts, $key);

      // Uses our breakpoint mixin to specify what should happen on the current
      // breakpoint in the loop.
      // Important: Adjust this if using a different mixin or strategy.
      @include breakpoint($breakpoint) {
        // Loop through the number of columns on this breakpoint.
        @for $i from 1 through $column-count {
          // Creates :nth-child selectors for each column. For example, in four
          // columns we would have the following selectors here:
          // &:nth-child(4n+1), &:nth-child(4n+2),
          // &:nth-child(4n+3), and &:nth-child(4n+0).
          $remainder: $i % $column-count;
          &:nth-child(#{$column-count}n+#{$remainder}) {
            // Important: this relies on the use of $zen-column-count, which is
            // specific to Zen Grids. $zen-column-count should be replaced with
            // a variable that represents how many columns you're using
            // within the current breakpoint (or globally).

            // How many columns of the general grid on my page should one
            // column of this specific grid take up? For example, if the whole
            // page uses 12 columns, and we have a 3 column grid going for
            // these elements, $page-grid-column-span would be 4.
            $page-grid-column-span: $zen-column-count / $column-count;
            // Which column should this specific column start on?
            $page-grid-column-position: 1 + (($i - 1) * $page-grid-column-span);

            // Important: adapt this if you aren't using Zen Grids!
            // If you are: this is where all the magic happens.
            // http://zengrids.com/help/#zen-grid-item
            @include zen-grid-item($page-grid-column-span, $page-grid-column-position);

            // Clear the first item in every row so they don't stack on top
            // of each other.
            @if $remainder == 1 or $column-count == 1 {
              clear: both;
            } @else {
              clear: none;
            }
          }
        }
      }
    }
  }

  // A clearfix so elements following this grid will be placed correctly.
  & > div:after {
    content: "";
    display: table;
    clear: both;
  }
}

With that breakpoint, your styles elsewhere become as simple as this:

// Create a grid of unformatted views rows that has one column on mobile, two
// on tablet, and four on desktop.
.view-id-fancy-grid {
  @include breakpoint-grid-breakdown(1 2 4);
}
// Create a grid of unformatted list items that has one column on mobile and
// tablet, and two on desktop.
.list-of-items {
  @include breakpoint-grid-breakdown(1 2, $breakpoint-mobile $breakpoint-desktop, '.list-item');
}

The first example will generate the following CSS structure using Compass:

@media all and (min-width: 320px) {
  .view-id-fancy-grid .views-row:nth-child(1n+0) {
    /* Zen Grid output to position the only column (removed for simplicity). */
    clear: both;
  }
}
@media all and (min-width: 768px) {
  .view-id-fancy-grid .views-row:nth-child(2n+1) {
    /* Zen Grid output to position column 1 (removed for simplicity). */
    clear: both;
  }
  .view-id-fancy-grid .views-row:nth-child(2n+0) {
    /* Zen Grid output to position column 2 (removed for simplicity). */
    clear: none;
  }
}
@media all and (min-width: 960px) {
  .view-id-fancy-grid .views-row:nth-child(4n+1) {
    /* Zen Grid output to position column 1 (removed for simplicity). */
    clear: both;
  }
  .view-id-fancy-grid .views-row:nth-child(4n+2) {
    /* Zen Grid output to position column 2 (removed for simplicity). */
    clear: none;
  }
  .view-id-fancy-grid .views-row:nth-child(4n+3) {
    /* Zen Grid output to position column 3 (removed for simplicity). */
    clear: none;
  }
  .view-id-fancy-grid .views-row:nth-child(4n+0) {
    /* Zen Grid output to position column 4 (removed for simplicity). */
    clear: none;
  }
}
.view-id-fancy-grid > div:after {
  content: "";
  display: table;
  clear: both;
}

The part that really makes the magic happen is the use of :nth-child. The Internet Explorer wizards among us may remember that IE 8 and lower don't support :nth-child by default, so you'll need to use Selectivizr to do so. There's a Selectivizr module if you need it.

Less comments, please!

For the brave souls who have wrapped their brains around what's going on:

// Breakpoint Grid Breakdown
// Displays a grid of items with a dynamic column count across breakpoints.
// For use with Zen Grids and a breakpoint-oriented mixin.
// @author Gus Childs http://drupal.org/user/1468898
//
// @param list $column-counts
//   A list of how many columns should exist on the respective breakpoints.
// @param list $breakpoints
//   A list of breakpoints to be used in the 'breakpoint' mixin. Corresponds
//   directly with the $column-counts list. Defaults to those commonly used.
// @param string $selector
//   The selector of each individual grid item. Defaults to 'views-row'.
@mixin breakpoint-grid-breakdown($column-counts, $breakpoints: $breakpoint-mobile $breakpoint-tablet $breakpoint-desktop, $selector: '.views-row') {
  #{$selector} {
    @each $breakpoint in $breakpoints {
      $key: index($breakpoints, $breakpoint);
      $column-count: nth($column-counts, $key);

      @include breakpoint($breakpoint) {
        @for $i from 1 through $column-count {
          $remainder: $i % $column-count;
          &:nth-child(#{$column-count}n+#{$remainder}) {
            $page-grid-column-span: $zen-column-count / $column-count;
            $page-grid-column-position: 1 + (($i - 1) * $page-grid-column-span);
            @include zen-grid-item($page-grid-column-span, $page-grid-column-position);
            @if $remainder == 1 or $column-count == 1 {
              clear: both;
            } @else {
              clear: none;
            }
          }
        }
      }
    }
  }

  & > div:after {
    content: "";
    display: table;
    clear: both;
  }
}

Wrapping up

We understand that this can be overwhelming for someone who isn't extremely familiar with Sass and Zen Grids. While this won't be a plug-and-play solution for the faint of heart, we hope it will get some folks thinking and set others out on the right foot. If you end up using this on a project or have any suggestions for improvements, we'd love to hear about it!

If you'd like to easily grab the code or perhaps even submit a pull request, it's on GitHub!

Coming Down the DrupalCon Portland Mountain

dave — Mon, 03 Jun 2013 14:00:00 +0000

It’s been one week since we returned from Portland for DrupalCon 2013, and I feel like I’m almost caught back up. The time in Portland was fantastic (as DrupalCon usually is). For CHROMATIC, we basically had two trips: most of us went and spent the weekend up on Mt. Hood and then came back for the ‘second’ trip which was the week in Portland for DrupalCon.

While the first trip (or weekend) wasn’t directly related to Drupal, we did the spend the time with some of our best friends in the Drupal community. And just as we did in Denver last year, and we had an amazing time. We were literally able to ‘come down the mountain’ after a day of hiking around lower Mt. Hood.

Chris and I are all about the time lapse craze that is currently happening, so the drive from the mountain to Portland was captured on our GoPros, one safely mounted within the car and the other mounted to the roof (thankfully, both cameras made it!).

Back to work…

I was able to attend the Drupal CXO event on Monday before the conference officially started. It was a great experience to get to meet and talk with a lot of the other company owners, partners, and managers. It was one more place where I was really able to see the Drupal community coming together and sharing in a very open way. I feel like I was able to take away a few valuable lessons from the day:

[Almost] All small Drupal companies are dealing with the same issues: resourcing, cash flow, growth (too much and too little), dealing with bad clients, partnerships, product development, dedicating time to the company v. time for clients, and the list goes on. The takeaway here was to not get too hung up on any single issue and to remember that if there is something that we as a company are struggling with, there are probably others struggling with it, too. And in that same vein, that it is ok to share struggles and solutions with the community.
Tracking all time related to both internal and external work is the only way to really understand profitability, but it can be really tough either way.
There are a tremendous number of talented people working in this industry and I feel very lucky to be a part of it!
To really fit in with the Drupal CXO crowd you need to wear a company t-shirt and a sport coat or blazer…

There were a lot of additional connections made during the rest of week and some sessions that I really enjoyed. Here are my top five (in no particular order) and some of the points that I took away from them:

Development by the Numbers by Anthony Ferrara (@ircmaxell)
- To be honest, I kept up with the first half of the session and then it got a little over my head, but overall I feel like it was very thought provoking.
- Measuring code complexity is tough, but we need to care about it
- Cyclomatic complexity is more or less the number of ‘decisions points’ in a routine, an N-path complexity is the number of ‘unique paths’ and these are not always equal (watch the presentation with the slide to really understand this one)
- Using tools like PHPLOC can really help to determine how complex your code is, but this doesn’t really provide answers to what to do about it.
- Reducing the complexity of your code will increase the long term ability to maintain the system that you have built.
Mistakes Agencies Make by Seth Brown (@sethlbrown)
- ‘The blood of a unicorn will keep you alive, even if you are an inch from death, but at a terrible price.’ – J.K. Rowling
  - Seth used a lot of quotes to communicate some great points. He warned agencies not to drink the blood of unicorns, meaning at a basic level don’t work your company to death just to make a profit.
- ‘How sad it is! I shall grow old and horrible and dreadful. But this picture will remain young. If it were only the other way.’ – Oscar Wilde, The Picture of Dorian Grey
  - Growth is really tough! Knowing when and how much to grow (or not) is really hard to understand. The recommendation was to try to keep and maintain at least 10% of your annual revenue in the bank for considering growth. In addition, you need to have a planned strategy for growth.
- ‘We can’t solve problems by using the same kind of thinking we used when we created them’ – Albert Einstein
  - Diversifying your clients, partnerships, and work is critical to success.
  - Taking on risk isn’t a terrible thing (if it’s managed properly).
  - ‘Allow for healthy dissent’
    - Just because you are running a company or are the project manager doesn’t mean you always know what’s best; sometimes the best innovations come from the bottom up, and not the top down.
Remotely Virtual by Karen Stevenson (@KarenStevenson)
- Remote and virtual are not interchangeable words. The Drupal project is run by a ‘virtual’ team. However, we are not a ‘virtual’ company, we are a real company with remote employees. It is a subtle but important distinction.
- Remote is everywhere! Teams that are on different floors in the same office can be just as remote as teams that are in different locations all around the world.
- The Five Commandments for Team Members was a great take away:
  - Thou wilt spend much time on the phone!
  - Thou must be visible and accessible in virtual channels.
  - Thou must not disappear without explanation.
  - Thou must over-communicate.
  - Thou must know thy virtual tools.
- Having common tools and team intranet can be very beneficial to both productivity and team building/camaraderie.
- Time tracking is really, really important!
- In addition to the aforementioned points, there were many more great takeaways for managing teams, both in person and remotely. Moreover, she provided a number of valuable insights and ideas to consider when working with your clients remotely. Watch the session and check out the slides!
Reponsive Discovery: The Underpants of a Great Web Project by Steve Fisher (@hellofisher)
- “Collaboration is far better than competition.”
- Design should focus on the human element and not just the technology.
- It is really important to work together to try to solve issues face-to-face. Most people don’t work in the same place as their clients and in a lot of cases not even the team works together. The concept of working together as a team adds a lot of strength to a project.
- Getting out and actually talking to your end users can really help define the user experience that you are creating.
Weathering Storms; How Robin Hood uses Drupal to fight poverty by Steven Merrill (@stevenmerrill), John Robert Wilson (@JohnRobertWilso), Heather Johnson (@johns582), Molly Byrnes (@mabfire), and Brian McMurray (@bmcmurray)
- First and foremost, Robin Hood is awesome! Check them out at http://www.robinhood.org/.
- Using Bean (https://drupal.org/project/bean) and Embeddables (https://drupal.org/project/embeddable) is a great approach to providing content editors a very dynamic way to create pages and manage content. Using this on Robin Hood, they were able to really empower the content editors.
- Drupal (with the right hardware…and Steven Merrill) can scale to handle some CRAZY traffic!

These are just a few of the key points and things that I feel like I learned while at DrupalCon. On a personal level, I had a great time! I really enjoyed getting to spend time with friends, making some new ones, and bonding with the CHROMATIC team. Planning for Austin has already started – hope to see you there!

PS – If you like food and are headed to Portland, then I have two recommendations for you. The first, which is probably in my top 20 (maybe 10) meals, was at OX. The clam chowder was the most unique I’ve ever had (and I LOVE clam chowder). The second recommendation is Little Bird. Not only did they have a really awesome aesthetic, the food and service was fantastic!

The Black Magic Effect

chris — Fri, 24 May 2013 04:31:38 +0000

I’ve been working with Drupal since the days of Drupal 4.7. Back then I was a green intern at the Iona Group working on some very basic Drupal sites. And when I say “green” I mean, I didn’t know anything about Drupal. In fact, I really had only begun to understand HTML and CSS (I distinctly remember a CSS Zen Garden assignment giving me fits). A CMS and dynamic websites in general must’ve seemed like “black magic” to me. What do I mean by “black magic”? I mean being completely unsure of how the hell something was built on the web. Black Magic.

Anyways, I’ve been reflecting a lot lately on my career and the growth of CHROMATIC. Through that, I realized how much I now take for granted. What I mean is, the “black magic effect” is no longer something that occurs to me (at least not often). I can now easily look at a piece of functionality on the web and figure out how the developers pulled it off. I can look at the source code and know they’re using jQuery for front-end effects. I can look for “tells” in the document’s head to see what CMS they’re using. I can use Dev Tools to inspect CSS3 styles and know exactly how they pulled off that slick gradient.

I take all of this for granted. From the skills I’ve learned to the tools I rely on every day, this stuff is just a part of my routine. It wasn’t always this transparent. When I first started developing websites, I realize I simply didn’t know what I didn’t know. I didn’t have the knowledge and the experience I have today. ~~For new developers, this stuff can be hard.~~ This stuff is hard.

All that said, I wanted to write a short guide for new Drupal developers; the guide that I wish I would’ve had when I started. Sort of a short outline of stuff that would’ve been helpful to me back when I was cutting my teeth.

Learn the basics

Knowing how to program (even just the basics) can get you a long way. If you can write basic PHP and understand basic programming principles, you’re well on your way. Get your hands dirty with some tutorials on variables, conditionals, loops, functions, etc. and you’ll have a foundation to build on. A fundamental understanding of these things is the basis for life as a developer. Without them, much of the web will seem like black magic. This ground-up approach isn’t the only way to learn, but I sure wish I would’ve learned this way. This looks like a very good roundup from Drupal.org itself.

From there, try reading some code (like that of the examples module). I can’t tell you how much I’ve learned (and continue to learn) simply by reading code. Seeing the actual code that runs a module will often times get you to the “Aha!” moment where you understand how something is actually done.

The Drupal Web Developer Toolbox

Here’s a rundown of things I use just about every day: (sorry, I’m a Mac guy)

Chrome Dev Tools – in browser debugging of HTML, CSS and JavaScript (I currently prefer this to Firebug)
Devel module – THE debugging module for Drupal
Drush – drupal control from the command line
You need a top notch text editor. These are the standouts for me:
- Sublime Text 2 (my favorite)
- BBEdit
- Coda
Tower – GUI for Git on the Mac, great for Git beginners
Sequel Pro – the best GUI for db management on the Mac
1Password – sane password management

Tinker

This is probably the best way to learn, in my opinion. Just get in there and get your hands dirty. The beauty of what we do is that there is very little cost to tinker. Other professions have greater expenses to learn. Painters need paints, brushes, etc. Mechanics need parts, tools, and garages. We need a text editor and an internet connection.

If you want to be a module developer, start by writing a simple module and tinkering with hooks. Maybe try to replicate the functionality of a simple module. Or follow the Module Developers Guide on Drupal.org (your new home away from home). The examples module (mentioned above) is also a great place to start.

If you want to be a themer, try to replicate your favorite website’s look and feel with a custom Drupal theme. I started using Zen as the base for my themes years ago and haven’t looked back. Zen is great because it’s really well documented and gives you a great jumping off point for many of the most used theme hooks.

Learn Git

I’ll be honest. Git was probably the last thing I learned that seemed truly like black magic at the time. In fact, it still feels that way sometimes. If you want to be a true developer these days, you’re going to have to learn to work with version control systems. Git isn’t the only version control tool, but it certainly is one of the most popular. This is the version control system Drupal uses, so for new devs looking to work with Drupal, it’s a pretty safe bet.

Read the online version of Pro Git to get started and consider buying Tower if you’re new to the command line. Focus on understanding commits, pushes/pulls and merges. This will be a good start. At CHROMATIC, we use Github to host all of our project repositories, so you might try their services as well. GitHub is your friend.

Command Line is also your friend

I avoided using the command line for years. It scared the shit out of me. Now, I spend lots and lots of time there. For me, I didn’t quite get why I’d want to use the command line until I started using Drush. It was only then that I realized how much faster you can get (most) things done from within a terminal window. It takes some getting used to, but once you learn the basics, there is a whole other world of computing out there. The command line is powerful and virtually all devs can benefit from being familiar with it. My friends at Lullabot have a great series on learning the command line available for free on their Drupal training site Drupalize.me.

Sharpen, Tune, Refine

Being a web developer means adaptation. The web is an ever-evolving beast and if you want to be a developer ten years from now, you’re going to have to continue to learn and refine your skills. This was one of the main reasons I got into this field. I love getting better, learning new things, not knowing everything. As a rule, I try to spend five-ten hours a week on honing my craft. Whether it’s reading blog posts on emerging technologies, following code tutorials or trying out new modules, I try to keep up on things as best I can. Making time to continue to learn is really important. I can’t stress this one enough.

Let Go

This could be an entire post on its own. The point here is that it’s OK to not know everything. No one does! It’s OK if you don’t yet know Git. That doesn’t mean you can’t make kick ass websites. It’s OK if you’re still writing vanilla CSS, that doesn’t mean you can’t make beautiful themes.

If I’m honest, this is the hardest one for me. I’m always thinking, “Shit. I really need to learn X or get caught up on Y.” The part I often forget is that you can’t know everything. Maybe I’m an awesome module developer but I’m not the best with Sass yet. That’s OK!

Wrapping Up

I’m hoping developers new to Drupal (or development in general) find this post useful. I’d hardly say this everything you need but I think it will get you headed in the right direction. Leave a comment if you have things you’d like to add and happy Drupaling!

Contact Us

admin — Fri, 10 May 2013 00:00:38 +0000

Google recommends following the industry best practice of using responsive web design to decide the rendering on each device.

admin — Thu, 09 May 2013 12:58:12 +0000

Google

77% of mobile searches take place at home or work, only 17% on-the-go, according to Google.

admin — Thu, 09 May 2013 12:56:09 +0000

Google