Color does not add a pleasant quality to design—it reinforces it.
~ Pierre Bonnard

Starting a website from a blank slate is always a wobbly moment. You’ve got this new client whom you’re wanting to genuinely help and impress, you’ve never met this person before (most of the time), but because you’re a designer you’re required to read their mind and produce a piece of work that encompasses not only their needs as a company or product, but also satisfies their inner artist. Now that’s not daunting at all, is it?

It’s been a constant journey for me to make this initial design process as simple as possible. There have been many helpful techniques and questionnaires to hand over to the client in the hopes that they answer honestly and can help ease you into creating something they’re going to like, but nothing is fool-proof and on occasion your final design ends up in an entirely different direction than when you first started (see Oatmeal for some giggles at this).

So could there be something more exact to help this initial design process? Could there be a way of quickly extracting views and thoughts for overall layout and colors from the client without spending hours and hours in [enter your favorite web design application here] to get from point A to point B?

Enter Colorscripting.

Used most notably in the film industry, Colorscripting is a layout of thumbnails that are used to show a broad overview of how a story/film/etc. will feel and flow from a high level by concentrating purely on blocks of color or very small abstract images of the real deal. It essentially can get the kinks out and in turn produce better pacing from scene to scene. Think of storyboarding, but a blurrier, color-dependent, tinnier version of it.

For some companies—such as Pixar—it’s an essential part of their animation process and that got me thinking—if it works for animation, for illustration, for film—why can’t it work for web design?

So I set myself a task to give it a shot. We had an awesome internal project that needed a website and my goal was to create 5-6 modestly small thumbnails that would get across 2 things to the client (or in this scenerio—my bosses): basic layout and basic colors. Here’s what I came up with:

I presented the colorscript theory, I presented the thumbnails (which, noteably, took about half the time it would have taken to do 2-3 comps of a full size view) and the verdict? Success.

In less than an hour talk with the them, I now had the direction to go with the site design, the layout to take, even the main background image to jump off of. There were no discussions of “this word is wrong here” or “this button isn’t round enough” which I feel always end up being discussed in initial design reviews and almost always have no bearing on the initial design goal.

So in short, colorscripting achieved: less time designing things that aren’t going to get used, more design directions (because they’re small you can make lots of them!), less attention to moot details, bigger attention to overall layout and color… could there be a downside to this?

I would love more than anything to try this on an unknown client, but yet I feel like there may be facets to it I’m not seeing. So this is where I turn to you oh people-of-the-internet. I have a theory and I want to hear your feedback. I want to know if you think this process has any potential—have you used something similar? How can I make it better? How can it be hindering? Is it complete bollocks?

I can see some drawbacks with it (thumbnails, wtfbbq? how am I supposed to see it?!!!111), and perhaps it will be a discussion per the beginning of a project if it should even be used.

However, I like that the first introduction to it—albeit internal—went smoothly and feel like this may be a very useful method for designers to add to their collection.

What do you think?

There’s one stereotypical piece of advice that I disagree with: Common wisdom says to hide your Facebook profile from potential employers, because it might scare them away. “A recent survey commissioned by Microsoft found that 70 percent of recruiters and hiring managers in the United States have rejected an applicant based on information they found online,” says CNN.

But let’s consider the flip side: what percentage of hiring managers have hired an applicant because her Facebook profile fleshed out the personality behind her already-strong resume? When I’m sorting through resumes, Facebook is an invaluable tool to help me find likeable people who will be a good fit for my team. Granted, I might be an easy target. I’m young, I know how this stuff works and I’m not going to dock you for a few red-Solo-cup photos. I think I have a few on my feed myself.

Maybe most recruiters and hiring managers aren’t as cool as me, but let’s give them a little credit. If you’re a generally standup person whose feed is full of innocuous updates and photos from the lake, nobody’s going to throw your application away because of it. Your Facebook feed is a mini introduction to you, and generally it’s good for a hiring manager to know more about you than less. She might remember you as the applicant who loves to fly-fish or who has twin daughters. It will help you stick in that person’s mind.

In fact, I’d go so far as to say I distrust people who hide their feeds, particularly applicants in their early 20s. If you’re a hotshot coder straight out of college and I can’t see into your feed, I know it’s probably because it’s full of penis jokes and beer pong photos you don’t want me to know about.

But if you’re 23 and your feed shows me there’s more to your life than Madden and Coors Light—well, young’un, that’s a serious leg up.

So to sum up: If you’re generally a good person/employee, there’s no reason to hide your profile, and it might actually help you get the job. If you: (a) badmouth your employer, (b) are a slacker pothead, or (c) spout culturally insensitive bile on your feed, well, make sure you’re applying for jobs at companies where that’s encouraged. Or maybe consider that those things might be why you’re surfing the job boards in the first place.

And then CSS 3 happened. Gradients! Box shadows! rgba! Mother-effing hsl()! It was a wonderful time: Subtle color effects and variations that were previously the exclusive province of bitmapped background images were possible via straight up CSS. And as my designs in 2008 quickly filled up with drop shadows and gradients on everything humanly possible, I couldn’t help but notice that my style sheets were just as quickly filling up with all the color values I needed to support them. I’m sure this looks familiar:

background: rgb(157,213,58);
background: -moz-linear-gradient(top, rgba(157,213,58,1) 0%, rgba(161,213,79,1) 50%, rgba(128,194,23,1) 51%, rgba(124,188,10,1) 100%);
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,rgba(157,213,58,1)), color-stop(50%,rgba(161,213,79,1)), color-stop(51%,rgba(128,194,23,1)), color-stop(100%,rgba(124,188,10,1)));
background: -webkit-linear-gradient(top, rgba(157,213,58,1) 0%,rgba(161,213,79,1) 50%,rgba(128,194,23,1) 51%,rgba(124,188,10,1) 100%);
background: -o-linear-gradient(top, rgba(157,213,58,1) 0%,rgba(161,213,79,1) 50%,rgba(128,194,23,1) 51%,rgba(124,188,10,1) 100%);
background: -ms-linear-gradient(top, rgba(157,213,58,1) 0%,rgba(161,213,79,1) 50%,rgba(128,194,23,1) 51%,rgba(124,188,10,1) 100%);
background: linear-gradient(top, rgba(157,213,58,1) 0%,rgba(161,213,79,1) 50%,rgba(128,194,23,1) 51%,rgba(124,188,10,1) 100%);

The new vendor prefixes weren’t helping much either. As someone who develops in Firefox, I couldn’t tell you the number of times I’d change, say, a color in the -moz-linear-gradient selector, and forget to make the same update to the webkit gradient. D’oh. Hope you Chrome and Safari users liked hot pink and purple together.

Since I started using SASS, however, I’m happy to report that I’ve been able to return to the halcyon days of only needing to use a handful of hex values in my style sheet. In fact, when I start a new project, I usually only need four. Here’s my workflow:

First: Create SASS variables for your basic colors

There’s no one-size-fits-all solution here, and obviously every project is different. However, I find that most apps and sites utilize four main colors: A brand color, an action color, a function color, and an alert color. (For the purposes of this post, we’ll use my best guesses at Facebook’s colors as an example.)

$brand-color: #3b5998;
$action-color: #67a54b;
$function-color: #f2f2f2;
$alert-color: #b22727;

Second: Lighten your load. Or darken it.

Once you’ve defined your basic colors, let SASS’s amazing lighten() and darken() functions create the tints for each.

$brand-color-light: lighten( $brand-color, 10% );
$brand-color-lighter: lighten( $brand-color, 20% );
$brand-color-dark: darken( $brand-color, 10% );
$brand-color-darker: darken( $brand-color, 20% );
 
etc., etc. for all your colors...

You’re going to want to tweak the percentages on a per-color basis here to get a nice gradation. (It should also be noted that SASS also has functions for dynamically adjusting a base color’s saturation, hue, and a whole bunch of other amazing stuff I feel like I haven’t scratched the surface of yet!)

Third: Set up your gradients, box shadows, etc.

Once you’ve got a whole bunch of nice tints for each of your base colors, setting up some mixins to use is pretty straightforward:

@mixin brand-gradient {
  background: url( imagefallback.png ) repeat-x $brand-color-darker;
  background: -moz-radial-gradient(center, ellipse cover, $brand-color 22%, $brand-color-darker 100%);
  background: -webkit-gradient(radial, center center, 0px, center center, 100%, color-stop(22%,$brand-color), color-stop(100%,$brand-color-darker));
  background: -webkit-radial-gradient(center, ellipse cover, $brand-color 22%,$brand-color-darker 100%);
  background: -o-radial-gradient(center, ellipse cover, $brand-color 22%,$brand-color-darker 100%);
  background: -ms-radial-gradient(center, ellipse cover, $brand-color 22%,$brand-color-darker 100%);
  background: radial-gradient(center, ellipse cover, $brand-color 22%,$brand-color-darker 100%);
}

… then simply rinse and repeat for all the gradients you’re going to need across your site or app:

But what about rgba and hsl?

Personally, I’m old school and tend to stick with hex values because they’re short and I’m used to ‘em. And when I do need rgba transparency, for example, SASS makes it easy for me to stay right within my comfort zone, as follows:

background: rgba( $brand-color, 0.5 );

Pretty cool.

The beauty of this approach is that I can change every single tint of a color sitewide by simply tweaking a single hex value. And by quarantining all this CSS in a separate colors.scss file, I no longer have all those gross, vendor-prefixed declarations cluttering up my main style sheet. So thanks, SASS, for simplifying my job and letting me color like it’s 2006 all over again. P.S. For the next release, if you could build something in to get me back the hair I’ve lost since 2006, that would be awesome. kthxbai.

It seems simple: “self.close()” or some such thing. The problem is, for security reasons, as a framed page, you can’t just close yourself. You can’t even access any properties on your parent across different domains because it violates the same origin policy. So how does the parent (in this case, some other website) know when an article has successfully been shared if we have no way of telling it?

It turns out that while we didn’t used to, we do now, thanks to HTML 5. After several failed attempts at setting shared variables on the window object and trying to access the contents of the iframe, only to be blocked by angry red “Unsafe JavaScript attempt to access frame” messages in the console, I discovered postMessage. It gives you a secure channel to send a message to another window or frame across different domains.

For the problem at hand, that means setting up a listener on the parent and a messenger inside the frame. Here’s what I ended up with (shown in Coffeescript):

Listener:

# For cross-browser compatibility
eventMethod = if window.addEventListener then "addEventListener" else "attachEvent"
eventer = window[eventMethod]
messageEvent = if (eventMethod == "attachEvent") then "onmessage" else "message"
 
# Listen for messages
eventer(messageEvent, (event) =>
  return if event.origin != myDomain
  setTimeout(@closeFrame, 3000) if event.data == 'autoclose'
, false)

Messenger:

parent.postMessage('autoclose', page.domain)

The interesting thing about the messenger is that we need to specify the domain (including protocol, hostname, and port, if applicable) the listener lives on. If we’re sharing an article on cnn.com (which we’ve injected our frame into with the bookmarklet), we need to pass ‘http://www.cnn.com.’ It’s also a best practice to check the origin of the event to make sure you’re only executing the callback if the message comes from a trusted source.

Now all that’s left to do is celebrate. I think I’ll go with a homebrew over a Dos Equis, though.

Factory.build(:listing)

Listing.new

It depends, of course. What are you defining in your factory? Just a few attributes? A couple of associations? Here’s what the one in question looks like:

Factory.define :listing do |f|
  f.sequence(:title) { |n| "Super Listing #{n}" }
  f.display_price "15"
  f.description 'Check out my super listing. Buy buy buy!'
  f.association :account, :factory => :confirmed_account
  f.association :zip
  f.association :category
  f.listing_type { |a| ListingType.offline }
end

After we dive a bit deeper, now there’s no question; using a Factory is going to be more resource-intensive than building a blank ActiveRecord object. Not only are we doing a ‘Listing.new’ but we’re also doing a ‘Zip.new’ and an ‘Account.new’ and we’re keeping track of previously generated titles; there’s simply a lot more going on. But how much slower is it, really?

All of these fields are set primarily to get the model to pass validation. That’s what makes FactoryGirl such a powerful tool; you can type Factory(:listing) and magically have a listing in your database without having to worry about any of that underlying validation logic. It’s excellent for generating test data that you can use in your Cucumber scenarios or if you’re testing out database queries.

In our estimation, the main speed difference wasn’t between using a Factory and not using a Factory. The biggest win would be avoiding the database. That’s why we’d often opt for Factory.build, because it doesn’t save the object you’re creating. A perfect use case is for testing validations:

describe "validations" do
  it "is valid" do
    Factory.build(:listing).should be_valid
  end
 
  it "is invalid without a title" do
    Factory.build(:listing, title: '').should_not be_valid
  end
end

This test clearly shows that a fully fleshed out Listing is valid, but when you remove the title, it’s not valid. And since we’ve called Factory.build, there’s no database hit. Right?

Surprise!

That’s what I thought, anyway. It turns out that while Factory.build doesn’t save your Listing, it does save your associations; your Account, your Zip, your Category, and any associations that those factories may have. Those long test runs are starting to make a lot more sense now.

Enough with all of this conjecture; how about some benchmarks?

Benchmark.realtime { 100.times { Listing.new } }
=> 0.0148091316223145 seconds
 
Benchmark.realtime { 100.times { Factory.build(:listing) } }
=> 19.3972871303558 seconds
 
Benchmark.realtime { 100.times { Factory(:listing) } }
=> 38.2170720100403

Fleshing out the attributes using Factory.build in this case is 1300x slower than building an empty Listing, and using Factory (to persist the Listing itself) is a whopping 2500x slower. To be fair, with an empty Listing Factory, it’s not much worse than doing Listing.new:

Factory.define(:boring_listing, :class => 'Listing') {}
 
Benchmark.realtime { 100.times { Factory.build(:boring_listing) } }
=> 0.0174689292907715 seconds

So the culprit here is building and saving those associations.

How about our validation specs above? Is there a better way? We still want to be able to quickly flesh out a valid model without hitting the database. For that, we have a much better option, Factory.stub:

Benchmark.realtime { 100.times { Factory.stub(:listing) } }
=> 2.69829893112183 seconds

This does what we actually intended to do in the first place, in this case 7 times faster than using .build.

This is clearly not an exhaustive analysis, but it has taught us a few valuable lessons:

1. Use caution in utilizing Factories. If you can avoid it, do so and test your model directly and you will get drastic performance boosts. This should be easy for most unit tests that don’t need to touch the database.
2. If you need a fully fleshed out model, such as for testing validations, use Factory.stub (build_stubbed in FG 3.0)
3. Keep your base Factory definitions as lightweight as possible: just enough to get a record to save; which is many times more important if you’re defining an association.
4. Beware of Factory.build, for it is deceiving.

All that said, FactoryGirl is a truly handy tool that we use in just about all of our Rails test suites. We don’t suggest that it’s inefficient or broken, but rather that you should keep performance in mind when writing your specs.

It was a great opportunity to finally give Bootstrap a try.

Created by Mark Otto and Jacob Thornton at Twitter, Bootstrap is a comprehensive front-end development framework that provides a foundation of markup/styles and javascript interactions for stuff you end up needing for nearly every project: reset or “normalize” CSS; CSS for grid layouts, pleasing typography, and common navigation patterns; and javascript plugins for drop downs, tooltips, accordions … the list goes on. Poking around Bootstrap for the first time, I was amazed by how much it encompassed; I couldn’t wait to give it a whirl.

Nevertheless, I still had mixed feelings about building on someone’s framework — most, to be completely honest, related to slight ego and control issues around my style sheets. CSS is my specialty; it’s my main area of expertise and my greatest professional pleasure. For the past three years, I’ve been constantly tweaking and updating my own personal, uh, “ultimate package” (I’d stop short of calling it a real framework) I use to start projects. I know the styles like the back of my hand by now, which makes for fast development and easy debugging.

My relationship to javascript, however, isn’t quite as cozy. Like many other front-end developers I’ve met who arrived in their jobs via the world of design, I find writing javascript rewarding but also fairly time consuming—I usually end up doing a fair bit of non-billable work double- and triple-checking my code. (And on a side note, one thing I love about working at 12 Spokes is having “real” javascript developers critique my work. I feel like I’m learning a ton and shedding a lot of bad habits I developed as a result of being mostly self-taught.) A speedy MVP project, however, is neither the time nor the place for poring over front-end code or reveling in teachable moments. And what made Bootstrap extra appealing was the prospect of having “good enough for Twitter” javascript plugins at my disposal.

So how’s it worked out so far? In a word (or two): damn well. Bootstrap’s javascript/jQuery plugins were everything and more I’d hoped they’d be. Without a doubt, they saved me time during development: I found them easy to style and hard to “break” (two drop downs in the same div? No problemo.) One major bonus surprise was the built-in icon set from Glyphicons. I didn’t always use their icons in the final iteration, but for quick prototyping, they were very handy. As for the CSS, it’s super well-written, and the default styles are really attractive jumping-off points for your own visual customizations.

Two main observations I’ve made so far during the project:

Bootstrap is more visually prescriptive than I thought it would be

This is by design: As its name suggests, Bootstrap is perhaps best suited to developers who want to bring their ideas to fruition without needing to learn the intricacies of CSS or request the help of a designer/front-end developer. The design of our app was 100% custom, however; and I found that unless you want your app to scream, “I was built with Bootstrap!!!”, you’ve got to do a fair bit of overwriting.

And during my efforts to overwrite Bootstrap’s default styles, there were occasions I found the framework overly prescriptive. The biggest culprit was typography. For some reason, the authors set font-family, font-size and line-height defaults for elements like paragraphs, instead of just adding those styles to, say, the body, and letting them cascade down (and thus be easily overwritten). So if you create a new style for a container where you want, say, a different font and color, what should be this …

.new-box {
background: red;
color: white;
font-size: small;
line-height: 1.5;
font-family: 'Comic Sans MS'
}

… turns into this:

.new-box {
background: red;
color: white;
font-family: 'Comic Sans MS'
font-size: small;
line-height: 1.5;
}
 
.new-box p {
color: white;
font-family: 'Comic Sans MS'
line-height: 1.5;
font-size: 11px;
}

Avoid the Gemset

If the Bootstrap authors read the above, they’d be well within their rights to say, “Whatever, dude. If you don’t like our type styles, don’t use ‘em”. And one thing I love about Bootstrap is that it’s super customizable. The authors make it easy to only download the components you need. However, we’re a Rails shop, so importing Bootstrap via a Gemset seemed like the natural way to go when we were setting things up. What I didn’t realize (and please let me know if I’m wrong here, world) is that when you import Bootstrap via Gemset, there’s no way to a) remove the CSS and javascript files you don’t need to load, or b) directly edit the Bootstrap styles. So what this leads to is unnecessary code getting loaded and a lot of overwriting Bootstrap defaults downwind in your own style sheet (instead of just editing the original styles). Before this app goes to production—and when we know exactly which Bootstrap components we’ll need to include—I’m going to ask Ethan to remove the Gemset, and I’ll create a custom download of the framework and use that instead.

Overall, though, Bootstrap is a major achievement in the world of front-end development and an incredibly generous gift to the industry from Twitter. I’m not sure I’m going to use its style sheets again (as someone who’s very comfortable with CSS, I just don’t think I’m its target audience there). The javascript plug-ins, however, will go right into my toolbox, and will definitely see the light of day on future projects.

“ERROR: Password must be 8-12 characters long.”

Oh, shoot me now. Better yet, shoot the developer who wrote that line of code. Who in their right mind puts an upper limit on the number of allowable characters? I understand the sites that push you into making a weak password more secure by adding letters, capitalization and special characters. I can work with that. I have a stable of passwords I use in these situations—throwaway passwords that meet various standards (must have a capital letter, must be a combination of letters and numbers, etc). And of course, I practice good password hygiene and have super-strong and unique passwords for important stuff like banking and email.

But putting an upper limit on the number of characters in a password? That’s absurd. In the end, I had to make up a new one, because all my regulars are too long.

Needless to say, now I can’t remember what it was.

I don’t have a master checklist for things that must be satisfied in order to commit. It’s more a feeling. If I’m adding a new method, does it warrant tests that I have not yet written? If so, I go back and write the tests. Could some code read a little nicer? Is it clear? What will someone reviewing this code think? What would I think of this code if I were reviewing it myself? Are all of my tests passing? What will they think of me?!

And naming your commits-ah! This is even more important when you’re not only communicating with people reviewing the code now or in the future but also a client (as we tie our commits to stories). Why does this code exist? What value is it adding, in layman’s terms? What edge case is it solving? When this update hits the client’s inbox, will it raise an eyebrow or make them think I’ve got everything under control?

This is the internal dilemma many (possibly overly self-aware) developers have many times each day. I deal with the crisis with a huge helping hand from a little unmaintained OSX tool called GitX. Many git GUIs exist, but GitX has the most lightweight and intuitive interface I’ve come across. It allows me to effortlessly make line-by-line commits (and discards) which enable me to craft my commits to tell the story of what I am trying to achieve. After one of those exploratory coding sessions, it lets me go back and review and refine my work before giving it a conscious seal of approval. Always having access to a real-time diff allows me to catch countless bugs, code smells, and junk that would otherwise clutter up the project. I feel lost without it.

Making a commit is not simply saving state–it is declaring victory over the problem at hand. A long series of these small triumphs is what makes a good project.

The more you read, the better it knows you and your tastes, and we should know—we spent a lot of time writing complex algorithms to determine how alike users are. We’re excited to see them in action!

It was 2006, and we’d been drinking the 37 Signals “Less is more” Kool-aid for a couple of years. We embraced the theory:
- Obviously, we collaborated using Basecamp.
- We used Google docs instead of Excel and Word. (Okay, it was 2006, and we used OpenOffice because Google Docs didn’t exist yet—but you get the gist.)
- We worked remotely and collaborated over Campfire group chat.
- We chose lightweight Blinksale and InDinero for invoicing and accounting, rather than bloated Quickbooks.

For the most part, the “less is more” philosophy really served us well. We’re still using Google Docs, HipChat for group chat, and we just bought a printer last week (reluctantly!).

But if I could give one piece of advice to the fresh-faced young entrepreneur I was in ’06, it’s this: When it comes to your accounting, always act bigger than you think you are. As a fledgling business owner, you might think Quickbooks—an overweight behemoth—is too big and cumbersome for you. But believe me, if (when!) your company starts taking off, you’re gonna want it.

This is where Past Erin steps in and calls Current Erin a sellout.

Now, Prior Self, don’t get all high and mighty on me. Believe me, Quickbooks is massive and definitely more accounting software than I need. But here’s why it makes sense: Small business owners, whether they run hair salons or software shops, are constantly reinventing wheels that all the other small business owners before them have invented. We’re all toiling in our offices trying to wrap our minds around health insurance options and 401Ks for our employees. We all have to figure out what the heck the federal 940/944 tax forms are.

There’s a gauntlet of minutiae that each small business owner has to untangle. As your business grows, you are going to spend more and more time on these minutiae and less time on your craft. By the time you realize you need Quickbooks, you’re going to be a very busy person. And believe it or not, using bloated software can lighten the load.

Here’s how:

- When you’re small, you can take half an hour write your own custom spreadsheet to calculate your profit and loss. When you’re big, you’ll appreciate that your accounting software does it for you in under 30 seconds.
- When you’re small, it’s not a big burden to invoice through Blinksale, record income through InDinero, and run paychecks through your bank. You don’t have that many invoices or that many employees. But when you’re big, you’ll want to be able to enter each invoice once and have the software automatically do the rest.
- People are going to want to look at your books someday. Maybe it’s a prospective landlord who wants to make sure you’re for real. Maybe it’s a banker whom you’re asking for a loan. Maybe it’s your tax accountant. Whoever it is, he or she is expecting your books to look a certain way. (Hint: the Quickbooks way.) I’m not saying it’s right or wrong, but when you hand them your home-cooked Google Doc, they’re not going to believe in you. I know, I know. Just because every other business in the world jumps off a cliff, that doesn’t mean you should, too. But you should.

Prior Self, you can definitely find other software that’s cheaper, lighter and can do most of what you need Quickbooks to do. But believe me, future self with thank you if you just act big from the beginning.