Hidden Secrets of the Chrome Developer Tools

In case you haven’t seen it yet, on Monday we posted our latest screencast, Hidden Secrets of the Chrome Developer Tools.

Ben was inspired to create this screencast when a coworker blew his mind by investigating a problem with the javascript debugger. He’d been using Chrome and the Dev Tools for over a year, but had no idea what he was missing. Rather than continuing to learn things when someone nonchalantly used a feature, he decided to discover everything all at once. This screencast is packed with everything he wished someone had shown him when he first started using Chrome.

The goal of this screencast isn’t to show you everything that the Dev Tools can do, but instead, to focus on the most useful parts of them, and the parts people tend not to know about.

Watch a quick preview:

As with all of our education products, you can buy it now for both yourself or your entire company.

Controlling color with Sass color functions

Sass comes with functions that can easily be applied to colors in your CSS properties. These functions, when used correctly, can be incredibly powerful. They take some of the sting out of choosing and manipulating colors. When used with variables, they can speed up development drastically.

Let’s start off with a creating variable for the color that we’re going to manipulate:

$base-color: #AD141E;

This is important for me for two ways:

1. It will allow color changes to be much more fluid and easy
2. Since I can’t be bothered to memorize hex values for each color, it helps me remember colors, eliminating the need to reference a photoshop mock every time I need a color.

Darken & Lighten

These two adjust the Lightness of the color’s HSL values. Sass will parse our hex color variable to hsl, then make the adjustments. You call them on the color with a percentage value between 0 and 100. I usually stay in the range of 3-20%.

darken( $base-color, 10% ) 
lighten( $base-color, 10% )

Saturate, & Desaturate

These will will adjust the Saturation of the colors HSL values, much like Darken and Lighten adjusted the Lightness. Again, you need to give a percentage value to saturate and desaturate. 

saturate( $base-color, 20% ) 
desaturate( $base-color, 20% )

Adjust-hue

This adjusts the hue value of HSL the same way all of the others do. Again, it takes a percentage value for the change.

adjust-hue( $base-color, 20% )

Adding Alpha Transparency

Using our hex color we can do a few things to get it to be a little transparent. We can call hsla, rgba, opacify, and transparentize. All of them accomplish the same thing, just in different ways. I stick to rgba as it comes most naturally to me which takes a color and a value from 0 to 1 for the alpha.

rgba( $base-color, .7 )

Tint & Shade

Our very own Phil LaPier has added to those base color functions. Both of these are accessible in Bourbon. They mix your color with a value of white (tint) and black (shade) and are similar to Darken and Lighten. They take the color and a % value for the change.

tint( $base-color, 10% )
shade( $base-color, 10% )

Getting more advanced

Once you have those down and you are looking for more control you can look into some more advanced color control with adjust-color, scale-color, change-color. These are for multiple changes in one color function. You can easily lighten the color and add some transparency all in one.

Some of the best places to use these color functions are for gradients, borders and shadows. When you need a slightly darker border and a slightly lighter inset shadow just adjust a color variable and let Sass do the rest for you. Buttons provide the perfect place to test out the functions. Check out some of the functions used on the thoughtbot buttons:

border: 1px solid darken($base-color, 20%);
text-shadow: 0 -1px 0 darken($base-color, 10%);
@include box-shadow(inset 0 1px 0 lighten($base-color, 20%));

Learn more about Sass, CSS and HTML during my Advanced HTML & CSS Workshop on December 8th and 9th.

Lazy man’s responsive web design

The Boston Globe recently raised the bar for responsive web design.

Please allow me to lower it.

For our playbook, I wanted to provide a pleasant reading experience for desktop and mobile web browsers. However, I’m lazy.

My answer to “what’s the simplest thing that could possibly work?” was a single-column layout with a maximum width that would also fit mobile devices:

margin: 0 auto;
max-width: 480px;

That makes the User experience section look like this on a desktop…

… and like this on an iPhone…

No media queries or other additional resizing tricks except for messing with the viewport a little and hiding the browser bar when possible:

<!--[if !IE]>-->
  <meta name="viewport" content="width=device-width">
  <script type="text/javascript">
    window.scrollTo(0, 1);
  </script>
<!--<![endif]-->

It also means fewer conditional statements, which we aim to eliminate.

max-width isn’t supported in IE6 but we don’t support IE6.

Responsive web design is already very elegant in its simplicity. My thought is that for use cases like landing pages and content sites, it can be even simpler using a thin, vertical one-column layout.

I’ve heard landing pages convert better using a vertical, single-column layout. The premise is anything that distracts the user, including navigational elements and sidebars, will hurt conversion.

For the playbook, the average time on the site is 4:40. So, I’m feeling pretty good that the layout is working well to focus readers on the content.

My guess is other content sites like McSweeney’s Internet Tendency do similarly well keeping its readers engaged on their 400px-wide desktop version:

With the addition of one line of code…

<meta name="viewport" content="width=device-width">

…they could make their mobile web version immediately readable without zooming instead of presenting a garish request to download software for “optimized” reading:

It’s so easy, even a lazy man can do it.

WIP it ♪♪♫♪ WIP it good

Our development process calls for a design component up front. Design is typically one or two weeks ahead of development so that by the time a developer is ready to implement the feature, there’s a pretty good idea of how the interactions will work, and even better, part or all of the markup has already been written. This introduces a problem where at any point in time there will be Work In Progress functionality that hasn’t been wired to the backend. This creates frustration and confusion for the product owner, who gets oh so excited to see a feature corresponding to the story they have just recently created, only to find out that it’s only a placeholder.

Displaying work in progress UI elements is also sometimes not an option, especially on an iterative development process where each week the app is shown to real users to gather feedback. Hiding .wip elements using CSS, commiting and redeploying to prime the app for user testing, followed by reverting the CSS commit in order to continue with development soon became old and cumbersome. There’s a better way to support the process.

You should go here on a new tab and click play. Also, here’s a picture of Devo. I’ve included a unicorn with a shining star to keep them company. Don’t worry, it’s Work In Progress.

What I present here is not ground breaking, but it is a well tested piece of code that you can drop into your app and will give your product owners the ability to view how the interface is shaping up. It still gives developers and designers the opportunity to continue implementing Work In Progress features on a live app without having to deal with too many feature branches, where keeping the markup and styles up to date with master at an early stage is an expensive moving target.

The idea is to have the ability to toggle visibility of Work In Progress elements of the app. For a developer or designer, it’s as simple as setting a CSS class of wip on any DOM element. For a user, pressing Ctrl-W reveals the WIP elements.

Let’s do this!

We practice Outside-In development, so let’s use Cucumber to specify this behavior:

Feature:
  As a product owner
  So that I can view what's work in progress
  I can press Control W

  @javascript
  Scenario:
    Given I visit the home page and the body is marked as wip
    When I press Control "w"
    Then the wip tags are visible
    When I press Control "a"
    Then the wip tags are visible
    When I press Control "w"
    Then the wip tags are not visible
    When I press Control "a"
    Then the wip tags are not visible

First, we use jQuery to set the wip class on the document’s body from within the step definition. Here’s the implementation:

Given /^I visit "([^"]*)" and the body is marked as wip$/ do |page_name|
  visit(path_to(page_name))
  page.execute_script("$('body').addClass('wip');")
  page.should have_css('body.wip')
end

Pressing Control W also evaluates javascript to trigger the event:

When /^I press Control "(\w)"/ do |character|
  code = case character
         when 'w'
           23
         when 'a'
           65
         end
  page.execute_script(<<-JS)
    var e = $.Event('keypress', { which: #{code}, ctrlKey: true });
    $('body').trigger(e)
  JS
end

Finally, checking whether the WIP elements are visible is a matter of checking the CSS classes:

Then /^the wip tags are visible/ do
  page.should have_css('.wip.visible')
end

Then /^the wip tags are not visible/ do
  page.should have_css('.wip')
  page.should have_no_css('.wip.visible')
end

I placed all of these steps definitions in features/step_definitions/wip_steps.rb

To make this pass, the jQuery implementation is simple:

$(document).ready(function() {
  $('html').keypress(function(e) {
    var codeForW = 23;
    if (e.ctrlKey && e.which === codeForW) {
      $('.wip').toggleClass('visible');
    }
  });
});

Here are some styles that handle WIP element visibility and give them a yellow outline:

.wip {
  outline: 1px solid #ff0 !important;
  visibility: hidden;
}

.wip.visible {
  visibility: visible;
}

When dropping this into your app, just remember that when a problem comes along, you must WIP it. Before the cream sets out too long, you must WIP it. When something’s goin’ wrong, you must WIP it. To WIP it, well, WIP it good.