I have now been with The Brick Factory for about three months and believe I have made myself right at home. I have worked with USAgainstAlzheimer’s, Melcrum, Panthera,  and Podesta. I have truly enjoyed getting to know everyone at my office as well as the wonderful clients that work with The Brick Factory. I thought this might be a good time to make my full introduction.

My background in marketing, entrepreneurship and publishing, allows me to take a unique approach to managing a client’s digital strategies. With emphasis on campaign management, creative marketing techniques and on-point writing styles, I have an eye for tailoring a project to engage current readers, potential clients and prospective contributors to establish the proper intersection between the needs of the client and the follow-through of the audience.

I moved to DC following a nearly eight year stint in Nashville where I earned a B.B.A with a concentration in Entrepreneurship from Belmont University. In my spare time I enjoy writing, reading, and spending time with my wonderful husband and two rambunctious puppies.

While my experience getting to The Brick Factory was quite normal, a few interviews, a job offer, and a start date, the same cannot be said for the following young interviewees. Perhaps this is a new trend that I happened to luckily sneak out of, or maybe these are just some hiring managers with a twisted sense of humor, or lastly perhaps this is a true test of a potential hire’s character. Whatever the case might be, I am beyond thankful that the crew here at The Brick Factory did not put me through this torture – not yet anyway.

What do you think, could you get this job?

Summer Internship at Brick Factory

The Brick Factory plans and executes world-class digital campaigns for non-profits, trade associations, advocacy groups and brands. We believe in simple solutions, setting clear goals and objectives, and providing great service to our clients. We believe a good website or campaign is never done and the launch of a website is the beginning, not the end.

The Brick Factory intern will be responsible for supporting our Strategists in conception, implementation and analysis of many digital initiatives. This includes website, social media, email, mobile and other digital marketing efforts that support new business and client programs. This position calls for an individual with strong communication skills, analytic skills and creative thinking ability. This position requires a highly resourceful individual who can think on their feet and can focus under pressure.

What you can expect from this internship:

• To Work: Do not be fooled, you will be put to work. Researching, creating, outlining, and executing strategic plans to the highest ability will be your average Monday.
• To Grow: The Brick Factory has high expectations of all interns and believes that in order for you to get the most of your time here, meeting and exceeding mutually defined goals is of top priority.
• To Compete: A summer internship at the Brick Factory will provide you will the skills and experience necessary to compete in the fast-paced, ever-changing digital technology industry.

What we expect from you:

• You’re a fun person to be around.
• You have a passion for work in the digital industry and are excited to explore the digital-sphere
• You’re a problem solver. You would rather figure out the best solution than be told how to do it.
• You’re organized. You can manage multiple projects at once and are dedicated to hitting deadlines.
• You have some experience with HTML, marketing and sales research, and analytics tools.

What you can expect from us:

• A great work environment, with plenty of opportunity to learn
• A metro accessible office in downtown Washington, DC
• Compensation during the extent of your internship
• A fun team of enthusiastic and talented people

The Details:

Dates May 15, 2013 through August 15, 2013 (can be flexible for the right candidate)
3 days a week in the office

Sound interesting? Take a look around our website, blog, Facebook and Twitter. If you think we’d be a good fit please send a resume and cover letter to jobs@thebrickfactory.com.

So much lies in a word. A single word can stir emotions, spark excitement, cause a raucous, and make you stop and ponder, all within the meaning, purpose and in the web world, the design of the word itself. Below is a list of some of my favorite typography based websites. I chose these for the use of tailored fonts specific to their brand, the use of specific color to highlight their chosen text, and the seamless integration of just the right number of fonts used.

Clean. Sophisticated. Modern.  

The New Yorker

The publishing world understood the importance of perfect typography even before the web world caught on, and The New Yorker shows us just how it is done. I would go ahead and bet you can picture what The New Yorker type looks like. Their logo offers a perfect blend of whimsy, polish and just a hint of pretentiousness, and this trickles down throughout the entirety of the site.

Corsair Distillery

This one may be just a bit of a biased choice on my part, being that I am from Nashville and actually used to work in this same building, but that is beside the point. Not only is this some wonderful whiskey, but the way they explain the boldness of their spirits just in the font and placement of text on their site show some skills in the typography department. The perfect blend of simply black and white with well chosen pops of color leaves us wanting to know more about their product, and by this I do mean a taste test is desired.

Beast and the Hare

Let’s be honest, when you are hungry and looking for a great restaurant, you want to get straight to the good part – the menu. What do they serve, what cocktails do they have, and are they still open? Beast and the Hare spelled it all out on this one page layout of their perfectly descript site. Clever and cool, this site is easy on the eyes and it lends itself to believe the food would also be easy on the lips.

Circle Meetups

The point of this site is to spark creativity within a group, or circle. Easy. Get people together, get a speaker and get creative. When it comes to their site, they kept it simple. In its simplicity it is actually quite genius. This site provides the information needed in a way that almost resembles a meeting invite you would add to your Google calendar. Nothing too fancy, yet cleverly displayed. While this is personal taste, I actually really like the oversized font throughout the homepage. I don’t feel that they are screaming at me, I feel that I my participation is quite zealously wanted.

Warby Parker

While I am not 100% positive that I reside on the cool team able to wear these frames, I would like to think that I am. I appreciate the model and the site they have built. The pops of color mixed with the smooth type they have chosen showcases an essence of calmness and tranquility. This sense of ease makes my purchasing of a third, or fourth pair of glasses less stressful and more rational – right?

In 2005, we started using WordPress for blog sites, and later, in 2007, we started to use Drupal for more complicated sites. Both can, to varying degrees, be called application frameworks (Drupal considerably more so than WordPress), and using these tools allowed us to create many websites covering a wide range of needs for our clients must faster than we could have if we had to write everything from scratch.

Actually, at one point before we adopted Drupal, we started to write our own CMS tool, and stopped when we realized that the amount of time we’d have to spend building it to meet our needs would be considerably larger than just using an existing open-source platform. And even if we succeeded in building something that met our standards, ultimately, we’d just be re-inventing the wheel that Drupal, WordPress, Joomla, and 40+ other CMS systems (according to Wikipedia) have spent years refining. And where’s the fun in that?

So, we’ve spent the last several years refining our skills with Drupal, even contributing back a few bug fixes and a Drupal module (Splashify) to the community, and we think we’ve gotten pretty good at Drupal site and module design and implementation.

In December, we started planning for Sway, our next internal project. We have some ambitious goals with Sway, and we wanted to get something to market relatively quickly, so it was obvious early on that we had to use a framework of some sort. This meant we couldn’t use the internal workings of ImpactWatch or Training, as aside from a few reusable components, they were never designed and developed to the point of being significantly useful in other applications.

It also put Drupal out of consideration, as what we had in mind would require so much custom work that the strengths Drupal brought to the table would be outweighed by the time we’d spend working against it. Also, we wanted a chance to use the latest and greatest technologies. PHP 5.4 has been available for just over a year, and we wanted to be able to use it. Drupal 7, by comparison, doesn’t take advantage of many of the new features in PHP 5.3, let alone PHP 5.4.

Ultimately, we settled on Symfony, and in January, started developing Sway using Symfony 2.1 (and quickly upgraded to Symfony 2.2 in March after it was released).

As an added bonus, working on Sway will give us a head-start in learning to use Drupal 8, which is expected to be released later this year. Core components from Symfony are being used in Drupal 8, so we’ll be able to put some of our experience working on Sway to use on any Drupal 8 sites we start working with. Both Symfony 2 and Drupal 8 use the Twig template engine, so our designers will have time to become familiar with Twig before we have to start using it on Drupal sites.

We’re looking forward to what we’ll be able to accomplish with Sway, and with future versions of Symfony and Drupal. This should be an exciting year!

The approach to building website has evolved along with the technology people use to brose the Internet.  In the last few years Flash has gone from ubiquitous to scarce.  And HTM5 has gone from an experimental technology to a fairly common way to build websites.

The rise of HTM5 and the fall of Flash have had a particularly dramatic impact on Interactive pieces.

I remember seeing this Arcade Fire HTML5 interactive film back in 2010, and being blown away by the possibilities it presented. While it is still pretty great, pieces like this have become more and more common over the last few years.  Following are five HTML5 interactive pieces I’ve come across in the last few months that push the boundaries of what is possible in browser.

(1) Pi’s Epic Journey

This piece uses stunning photography and video to tell the story of the making of Life of Pi.

(2) Every Last Drop

This piece tells the story of how much water the average person in the UK uses in a given day.  All of the animation effects are triggered by users scrolling down the page.

(3) North Pole Exhibition

Uses a combination of text, photos and maps, this interactive from Greenpeace tells the story of an exhibition to the North Pole.

(4) Teacher Test

This online quiz tests you on whether you have the base knowledge required to be a school teacher.  An HTML5 take on the classic online quiz.

(5) Century of the Child

This interactive is an online version of the Museum of Modern Art’s Century of the Child Exhibit. Great photography and extremely easy to use.

$sql = "SELECT * FROM ".$tableName." WHERE id=".$_GET['id'];
$result = mysql_query($sql);

This is perfectly valid code. In fact, if you look at a lot of examples today you will see the same thing. There’s a huge flaw in these examples, and one that has given PHP a bad name when it comes to security. It isn’t the fault of the language but of the way that many developers learned how to do things. PHP makes it easy to shoot yourself in the foot and it doesn’t help that developers keep showing new developers how to do it. Get gun, point at foot, pull trigger. That’s essentially what the above example is showing you.

So, what is so wrong with the example code? The problem is that we aren’t validating anything. Do we know what $_GET['id'] actually is? What happens if $_GET['id'] is set to something that isn’t an integer?

// $_GET['id'] = 'bob'
$sql = "SELECT * FROM users WHERE id=".$_GET['id'];
// $sql is now equal to "SELECT * FROM users WHERE id=bob"
$result = mysql_query($sql);

When mysql_query() runs it will return false. Depending on how well your code handles a false return, someone screwing around with the query variables will learn that we didn’t properly make sure that the id query variable is being checked. At the very least they learned that changing query string parameters does cause the code to change. Depending on the setup of our code, it might even expose what database we’re using. If it’s MySQL, they can get crafty and do something like this:

// $_GET['id'] = '1 OR 1=1'
$sql = "SELECT * FROM users WHERE id=".$_GET['id'];
// $sql is now equal to "SELECT * FROM users WHERE id=1 OR 1=1"
$result = mysql_query($sql);

That little OR 1=1 bit will cause the SQL server to return all of the data in the user’s database. Let’s take this a step further, and say that we are authenticating a user. Most of the examples would look like this:

$username = $_POST['username'];
// Using MD5 to hash passwords is bad, using ONLY as an example. Look into something like PasswordLib for a modern password solution
$password = md5($_POST['password']);
$sql = "SELECT * FROM users WHERE username='".$username."' AND password='".$password."'";
$result = mysql_query($sql);

We’re doing one thing correctly (forcing this data to come through the POST array), but we’re still not really validating that $username or $password are actually good valid values. We can still do the following:

// $_POST['username'] = "admin' -- "
$username = $_POST['username'];
$password = md5($_POST['password']);
$sql = "SELECT * FROM users WHERE username='".$username."' AND password='".$password."'";
// $sql is now SELECT * FROM users WHERE username='admin' -- ' AND password='oasdnifniuh3h48puahergler' 
$result = mysql_query($sql);

We’re in, and as a user where we didn’t even know the password. Why? The -- will comment anything after it, so we dropped the AND password= portion of the SQL and do the select based on just the username. It will return a single value just like the code will expect, so your code never knows that it was altered.

Both of these attacks are called “SQL Injection Attacks”, and is part of the OWASP Top 10′s #1 attack vector. The sad thing is that these are really easy to combat against. I see all the time on Reddit and Stack Overflow people asking for help and seeing this same sort of code. In 2013 we should have been able to stop this, but with years of old tutorials out there it is an uphill battle.

The reason that it sad to see this as still the #1 attack on OWASP is that it is easy to combat. The first and foremost is to stop using the mysql_* functions in your code. The module that handles those is old, and it doesn’t support the best way to handle SQL injections. Yes, it has mysql_real_escape_string(), but that relies on the developer remembering to use it. Better security comes from the developer having to not remember to do it and it just being built in.

Since PHP 5.0, PHP has shipped with something called PDO. PDO is a database abstraction layer that makes it easier to write cross-database code. If you write your app for MySQL, you can more easily port it to something like Postgres or MSSQL by doing nothing more than changing the connection parameter (assuming you haven’t written any engine specific code like using LIMIT, which MySQL and Postgres support but MSSQL doesn’t).

PDO has another big advantage in that it has support for something called a Prepared Statement. With a prepared statement, the SQL query is parsed by the engine by taking a SQL statement and a list of parameters and putting them together itself instead of relying on a fully built SQL statement. This becomes much safer because the DB engine does all the work on properly quoting the values coming in. The side effect of this is that the worry about the developer being safe is offloaded somewhere else, so by using PDO and prepared statements the developer doesn’t need to worry about if a parameter has been sanitized.

Let’s go back to our first example, with the $_GET parameter. What would this look like with PDO?

$sql = "SELECT * FROM users WHERE id=:id";
// $pdo is our PDO connection
$stmt = $pdo->prepare($sql);
$stmt->execute(array(
    ":id" => $_GET['id']
));
$user = $stmt->fetch();

It’s a bit longer, but not so much that that there is a ton of extra work involved. What we did was create an SQL statement using placeholders, which in PDO can either be a ? or named like our example, which was :id. We run our SQL through the prepare() method on our PDO connection, which returns a statement object. This statement object gets executed, and at the same time we pass in the values for our placeholders. We can then get the user by calling the fetch() method on the statement.

We can rest assured that the SQL code is now safe from injections. That’s it! That is the single most effective way to combat SQL injections.

For older legacy applications switching out to PDO can be a major undertaking. Drupal did this in Drupal 7, where they replaced their underlying database abstraction layer to use PDO. Drupal didn’t use the database specific functions all over the codebase which made it somewhat easier to swap out, but if your application is riddle with calls to mysql_* or pg_* functions you will want to replace them all with PDO commands.

Do your part to help clean up the bad examples out there. If you ever do new code, use PDO. If you ever give examples, do it using PDO. Maybe we can make the internet a little better, and help knock SQL injections (and other injection types) off of the top of the OWASP Top 10.

Readability

I’m stating the obvious here, but your blog should really be about your content.  The design should get out of the way and let the posts be the star.

Our primary focus in redesigning our blog was to better showcase the content itself  by increasing readability.  To achieve this we:

• Switched our primary font to Georgia.   We chose Georgia because it works well with the font used in our logo (Avenir), is a pleasure to read, and isn’t used on every site on the web like Arial. I think it adds a bit of elegance to the blog.
• Jumped on the big type bandwagon and upped the sizes of our fonts throughout.
• Switched from full justification of text to the justify left, ragged right style.  Full justification is more elegant and looks better on first glance, which is why it is still the dominant approach in book publishing.  Left justified, ragged right is easier to read online and has a bit more of an informal look, which we thought appropriate for our blog.
• Changed to a one column layout.  Our previous blog had a sidebar with a list of recent posts and a subscribe box.  We found that very few people were clicking on any of that stuff, and going to one column gives us room for larger images to accompany our posts.

Illustrations

We have a talented team of designers that we frankly don’t utilize as much as we should on our blog.  To rectify this we decided to have our design team develop quick illustrations to accompany most of our posts.  They did the illustration for this post, as well as for this one and this one.  I love them.  I think they really add something to our blog.

Responsiveness

Our new blog is completely responsive, so that the layout adjusts along with screen size.  This means it looks great on a desktop, tablet, or mobile phone.  Nearly all the sites we are building now are responsive to some degree, so it made sense that our own blog would be.  We think this is how sites will be designed moving forward.

Let us know what you think.

PHP is nearly 20 years old now, and today we have the tools to do proper unit and functional testing without having to go through the pain of writing those kind of systems ourselves. At The Brick Factory, we tend to use the Drupal CMS quite a bit, and thankfully Drupal has a proper testing system built right in.

Why Unit Test?

Unit Testing allows you to make sure that your code works as you expect it to. Let’s say you have a class that calls an API and returns customer information. If you always expect to get an array, you should test situations and make sure that you always get an array back. You don’t want your code to rely on that array and break all of a sudden when a boolean is returned, or a string is returned. By testing your code you are better able to say that your code works.

On the flip side, when you do discover a bug you can reproduce it in a test, and then once that test passes you know that you fixed the bug. Does that API you are calling sometimes error out when you don’t put dashes in the phone number? Well, you can reproduce that response and have your code handle it properly, and document that the bug is fixed with your tests.

The other nice benefit of unit testing code is that you make sure your code is not directly dependent upon any other code. To make unit testing easier the chunks of code should be separated out so that you can quickly mock up interfaces you aren’t testing. In our API example, we would have another object that generates fake API results for us to test since we are testing how we handle responses, not the actual API itself. If we decide to change the service we are using down the road, we can quickly swap out the API since it isn’t tightly coupled to our code.

How Testing Works

To properly test something, you need to write your tests, watch them fail, fix the failures, and then watch them pass. The reason for this is your tests set up the expectations for how you think your code will work, and then you need to make the code work against those expectations. If you build your tests after you already do your code you tend to ‘fix’  your tests instead of fixing your code when you find problems. In PHP you have to bootstrap your tests a bit and actually build classes and methods as you start to write your tests since PHP tends to not like classes that don’t exist.

There are a few different ways that you can run your tests. At the Brick Factory we tend to use Drupal for many of our projects, and Drupal ships with an implementation of SimpleTest. SimpleTest is a web-based test runner, and the Drupal module provides a way for modules to register tests with SimpleTest and then run them from inside Drupal. SimpleTest also works with drush, so you can run your unit tests through the drush command line program.

When building a module for Drupal you can include a mymodule.test file that the SimpleTest runner will launch to run your tests. You add a class inside this file that contains your tests and SimpleTest takes care of the rest.

Writing a Test

Writing a test is actually really easy (writing testable code is an entirely different issue though). To create a test, you need to create a test file. Let’s create a module that generates a block, and this block will output a list of repositories for a user on Github, a popular code hosting site. We’ll need to build something to talk to the Github API, and something to parse the results. Our module will be called tbf_github. Let’s look at building that second part.

Creating the Test Suite

The first thing we will need to do is create our test suite. A test suite is a class that contains a series of tests, and for Drupal it will either extend DrupalWebTestCase for functional tests, or DrupalUnitTestCase for unit tests. It will also need to need to implement the getInfo() method, which is a static method that returns some information about the test itself. Let’s build our first test suite by creating the file tbf_guthub.test inside of our module directory, and adding the code below.

class TbfGithubParserTestCase extends DrupalUnitTestCase {
    static public function getInfo() {
        return array(
            'name' => 'TBF Github Parser Unit Tests',
            'description' => 'Unit tests for the Github parser',
            'group' => 'tbfgithub'
        );
    }

    public function testGetRepoNames() {
    }
}

Functional vs Unit Testing

I mentioned that there are two different classes that extend your own test suite from. This is because Drupal allows you to do Functional as well as Unit Testing. The big difference is that Functional testing via DrupalWebTestCase bootstraps Drupal entirely. This allows you to do things like log in users, access things in the database, or render pages to test output. The downside is that functional tests are slow because Drupal is completely torn down, reconstructed, and invoked every test. It is very resource intensive.

Unit tests do not do anything like that. They strictly test the code you need, but that means you don’t have access to the database or users or anything like that. That’s OK! Unit testing shouldn’t rely on multiple systems.

Our First Test

When we created the test suite, we added a testGetRepoNames() method to our class. Tests in SimpeTest are methods that begin with ‘test’ for the method name, so you can also have extra methods that aren’t run automatically. Let’s write the first test, which should test to see if we get back the repo names we are expecting.

Before we do that, we need to create a skeleton for our class. PHP doesn’t like if if you call a class that doesn’t exist, so let’s create the class for our parser and stub out a method for parsing repos.

// In file Tbf_GithubParser.php
class Tbf_GithubParser {
    function parseRepos($response) {
    }
}

// Include our class
require_once 'Tbf_GithubParser.php

class TbfGithubParserTestCase extends DrupalUnitTestCase {
    // ...
    public function testGetRepoInfo() {
        // Get a stored response from Github so we don't have to hit the real API
        $response = file_get_contents('_tests/response_repo.json');
        $githubParser = new Tbf_GithubParser();

        $repos = $githubParser->parseRepos($response);

        $this->assertEquals(3, count($repos), 'Should have had 3 repos but ended up with '.count($repos));
        $this->assertEquals('myrepo', $repos[0]['name'], 'First repo should be named "myrepo" but it was named '.$repos[0]['name']);
    }
}

If we run this test right now, it will fail. parseRepos() doesn’t return anything, and that’s OK. The big point here is that now we know this doesn’t work, so let’s fix it.

// In file Tbf_GithubParser.php
class Tbf_GithubParser {
    function parseRepos($response) {
        return json_decode($response, true);
    }
}

Now if we run the test, it should pass if our $response JSON is correct. Since we’re using a canned response from a file we can make sure that the response has three repos and the first one has the correct name of ‘myrepo’.

That’s it. That’s unit testing as well as Test Driven Development.

Wait, why doesn’t the parser interact with Github directly?

One thing you will notice with the code is that the our parser doesn’t work directly with Github and just parses the result. Our code still doesn’t talk with Github. There’s a reason for that, and it’s called Separation of Concerns. Our parser shouldn’t interact with Github directly, just parse the results. Our parser shouldn’t care if we use curl, or streams, or whatever to get the response. It’s something else’s job to interact with Github.

By the same token, whatever object actually talks to Github shouldn’t care about the output. It should deal with talking with Github and just returning the response. By splitting processing out of the API interaction we can manipulate the responses any way we want. In our case, we’re turning the JSON into an array that we can get data from.

Properly separating out your responsibilities makes it much easier to test. In our test we didn’t need to actually interact with the Github API so our test was very quick. We’re also safe because of the API is down, our tests would break, or our tests will break if a repo we are testing is deleted. By keeping these systems separate we can make sure that our code still works. This is different than Functional testing, where we do want to test multiple systems at once to see if they are working together properly.

Running Tests

I glossed over this in the previous section, but in Drupal you can run tests two ways. One way is through the web test runner, and the other is from the command line using drush.

To run the tests via the web, go to the administration, Configuration, and then ‘Testing 2.x’. You will see a list of test groups to run. Just put a check next to the tests you want to run. Click ‘Run Test’ and everything will start to work.

The tests will run, and you will get a nice little readout about their status. Once all the tests are done, you can see which ones failed and fix them. If you have functional tests that extend DrupalWebTestCase these will take longer to run. Failures are red, warnings are yellow, and green is passed. You want everything green.

To run tests with drush, drop to a command line and run:

$ drush test-run --uri=http://mysite.local

and replace the –uri portion with the URL of your site. This will list all of the tests that are available in your site, and you can run them with:

$ drush test-run --uri=http://mysite.local NameOfTest

of you can use –all instead of a test name to run everything. This isn’t much faster than running it through the web interface, and it is a bit harder to read, but you can sometimes seem more information than what the web runner does. It also doesn’t break as easily as the web test runner.

Testing is a Good Thing

With a little bit of time invested up front, we can automatically know at any point if our code is working as we expect. It provides us with better structured code that can be extended quicker, and when we find bugs we can identify them quicker. Knowing that changes can quickly be tested against a larger codebase with the click of a button helps developers have confidence that their code is working.

Drupal makes it easy to get going with testing by providing various interfaces for writing and running your tests. Next time you need to write module code, take a look at making unit testing part of that process.

From a content creation standpoint, one of the things that has changed the most the last few years is the the headline.

When I first started writing blog posts ten years ago I treated the article headline as an afterthought.  I’d spend hours on a blog post and then approximately thirty seconds on the headline.   As I got a bit more savvy I started writing keyword-rich headlines with search engines in mind.

As Facebook and Twitter have taken off, my focus has evolved further.  Facebook and Twitter users are barraged with hundreds of posts/links a day and make the decision on whether to click or not in just a few seconds.  To succeed in this competitive environment you have to make your headline click-worthy.  A headline has to grab readers attention and compel them to click.  A click-worthy headline is a way of pushing the snowball down the hill.

One media company that gets the importance of headlines is Upworthy.  Upworthy requires writers to draft 25 headlines for every single article.  They then test the headlines to see which ones generate the highest click rates and use that as the permanent article headline.  All the effort pays off.  Upworthy has found that “an item’s traffic can differ by as much as 500 percent simply because of the headline.”

Here are some examples of click-worthy headlines I found on Upworthy today:

• Possibly The Most Devastating Response I’ve Ever Seen In An Immigration Debate
• This Is What It Looks Like When A City Fights For Its Schools
• Two Barking Dogs, A Mother Of Three, And One Outrageous Deportation That You Can Stop
• SWOON: Watch This Star Calmly Blow Apart Any Argument That We Can’t Solve Poverty In One Generation

The thing about these examples is that the content isn’t necessarily click-worthy in and of itself.  These aren’t listicles or articles about cute animals or Ryan Gosling.  These are pieces about immigration, the plight of our schools and poverty.  Great headlines are what make you want to click, not necessarily the subject matter itself.

As I work to improve my own headline writing, I’ve found these two simple tips to be helpful

1. I consciously think about what all the headlines I write will look like when I post them to Facebook and Twitter.  I still consider search engines, but my headlines are now written primarily for social networks.  As a result, my headlines have gotten a bit more casual and tongue and cheek.
2. I make myself write ten headlines for every article and take my time in choosing which one to use.  I haven’t gotten to the point of doing testing like Upworthy does, but by taking the time to brainstorm my options I’ve found the quality of my headlines has improved and I’m seeing more clicks (and shares).  I’m no longer just using the first headline I come up with or writing exclusively for Google’s bots.

I’m still not a great headline writer, as evidenced by the headline to this article.  But by giving more thought to the headlines I’m getting a bit better every time out.

The following quote from Dutch American reformer Jacob Riis hangs in the Spurs dressing room and serves the team’s unofficial motto:

“When nothing seems to help, I go and look at a stonecutter hammering away at his rock perhaps a hundred times without as much as a crack showing in it. Yet at the hundred and first blow it will split in two, and I know it was not that blow that did it, but all that had gone before.”

In the context of basketball, the quote is an obvious call for players to put maximum effort into everything they do.  Winning an NBA title is the culmination of years spent taking jumpers in the gym when no one else is watching.  To be great you have to pound the rock.

The quote is also an accurate description of what it takes to build and maintain a great digital program.

There are tons of organizations that want a great, successful online campaign but don’t want to put in the work.  The truth is there really aren’t short cuts.  The truth is that building websites and running digital campaigns is hard work that requires a significant commitment.  A successful web program isn’t the result of one transcendent idea so much as it is hundreds of small ideas implemented well.

To be great you have to write compelling content every week, and preferably every day.

To be great you have to optimize your email messaging and design.

To be great you have to make sure your website works in all browsers (even IE) on all devices (desktop, tablet and smartphone).

To be great you have to experiment.

To be great you have to test and then test some more.

To be great you have to pound the rock.