A blog by the Brick Factory The Brick Factory

10 Tools We Can’t Live Without

Like a lot of companies, the way our Brick Factory team works has changed dramatically the last few years.   We have moved away from buying traditional software to using web-tools hosted in the cloud. In some cases we have moved from traditional software (such as Microsoft Office) to web-based tools (such as Google Apps).  In other cases we have started using online tools we weren’t even really aware we needed (Browserstack, Mockvault).

In the spirit of sharing what we’ve learned, below are ten tools we use every day to do our work.

Google Apps

Every since we started Brick Factory our company-wide email and calendar system has been powered by Google Apps.  Over the last year Google Docs and Sheets have become our word processing and spreadsheet programs of choice due to the ease of collaboration and integration with our Google accounts.  As a company with a distributed workforce, we use Google Hangouts every day for our team meetings.

Google Apps is an essential part of everything we do.


Basecamp is our primary project management tool at the Brick Factory.  We use it to manage projects internally and to share resources and collaborate with our clients.

We sort have a love/hate relationship with Basecamp.  It’s greatest strength (it’s simplicity) is also its greatest drawback (it’s too simple).  Our team at the Brick Factory consists of 20 designers, developers and strategists.  Given our diverse skill sets and personalities, it is pretty much impossible to find a project management tool that is going to thrill everyone.  Basecamp comes the closest.


As a way of filling in some of the functionality holes in Basecamp, we recently started using Workstack.  Workstack is workflow management tool that allows you to view the Basecamp To Dos for each of your co-workers on a single calendar.  It makes resource management and internal scheduling much easier, saving us time.


Planbox is an agile project management tool we’ve started using on some of our larger development projects in lieu of Basecamp.   It is a bit cumbersome for managing our smaller projects, but is great for our larger builds where we follow a more formal project management process.  If you are using agile, we would recommend giving Planbox a try.


The rise of mobile and tablets and the proliferation of browsers has made testing websites a huge pain.  Browserstack makes it easier for web developers to test the sites they are building in different browsers running on different operating systems.


Mockvault is a nifty tool that allows you to present your design comps in browser, track revisions and collect feedback.  We started using it around a year ago and love it.


UXPin is an easy-to-use tool that allows anyway to create good, professional wireframes.  Our UX and design team doesn’t use UXPin for wires, but our Strategists use it to put together quick prototypes for internal and/or client review.


For a long time we used a custom system to track our time.  At the beginning of 2012 we started using Harvest for timesheets and haven’t looked back.  It is user friendly and includes powerful reporting tools.  We looked at every time tracking solution under the sun and Harvest is by far the best for our needs.


We recently started using Pipedrive as our company CRM.  We use it to track our new business efforts and to manage our contacts. We used Highrise for years and never loved it – it didn’t fit into our workflow and was inflexible.  We then tracked everything in Google Docs for a time as well.  We started using Pipedrive a few months ago and I love it.  It is perfect for us – it has the features we need while also being extremely easy-to-use.


When you work at web development firm, managing your online passwords is a huge pain.  You literally have hundreds of passwords to track and keep updated.  Passpack is a secure way to organize and share passwords among teams.  I would guess using Passpack saves our IT team a few hours a week that would be spent helping people track passwords down.

Do you have a favorite tool we should check out?

Drupal 8

What You Need to Know About Drupal 8

Drupal 8 is coming soon.  For those of us that work in Drupal every day, the release of Drupal 8 will be met with a mix of excitement (great new features!) and trepidation (learning the new version and converting old sites is a ton of work).  In an effort to help folks understand the impact of the release of Drupal 8, we have put together some quick answers to the most common questions we are getting.

When exactly will Drupal 8 be released?

The truth is that we don’t know exactly.  My best guess is that it will be released some time between March and June of 2014.  Drupalcon Austin starts on June 2nd and I suspect the Drupal community will push hard to release Drupal 8 prior to that conference.

Let me explain the reasoning behind my estimate.  Like most software platforms, Drupal follows the Alpha/Beta/Release Candidate software release life cycle.  For Drupal 7, there were 7 Alpha releases, 3 Beta releases and then 4 Release Candidates prior to the official launch of Drupal 7.

The most recent release of Drupal 8 is Alpha 7.  Given that there were 7 Alpha versions of Drupal 7, it seems likely Drupal 8 is very close to entering the beta phase.  Drupal 7 was officially released four months after the release of the first beta version.  Assuming the first Drupal 8 beta is released in January, I would guess Drupal 8 will be released at some point in May 2014.

What are some to the key features in Drupal 8?

You can find a good overview of the key new features here.

Here are some of the improvements our Brick Factory team is most excited about:

  • Drupal 8 is designed to be responsive and mobile friendly.  All built-in themes and the administrative pages are all designed to work well down to mobile.
  • For our Drupal 7 builds the Views module has become a vital tool.  In Drupal 8 Views will be part of core and much more integrated with other functionality as a result.
  • Content editing has been improved dramatically, with CKEditor built in as the default WYSWYG editor.  This should make Drupal much more user friendly.
  • Moving from Drupal 5 to Drupal 6 or Drupal 6 to Drupal 7 was/is a huge pain.  Drupal 8 will include content import tools that should make this process much easier.
  • The configuration management system in Drupal 8 is much improved over previous versions.

There is a bunch more.

How soon after the official release will you start building new client sites in Drupal 8?

We will probably wait two to three months after the release of Drupal 8 before we make it the default platform we use for new Drupal builds.  There are three main reason for our caution in transitioning to the new platform:

  1. While Drupal 8 will have been tested rigorously prior to its official release, it is still a new piece of software that will inevitably have bugs and security holes.  We typically like to wait a bit for these key issues to be addressed before building mission critical sites on a new Drupal version.
  2. When a major new Drupal version is released it usually takes awhile for modules to be updated to work on the new platform.  And some extremely popular modules in Drupal 7 will simply go away altogether.  Given this, we like to wait a bit for the module situation to sort itself out before starting to build in a new Drupal version.
  3. Developing websites in Drupal 8 is going to be really different from building in Drupal 6 or 7.  While we have already started learning Drupal 8, it will take us some time to develop the level of knowledge we have in Drupal 6 and 7.  We want to spend some time mastering the new platforms before we build client sites in it.

When Drupal 6 was released in 2008, we immediately adopted the platform and used it for some ambitious new site builds.  This turned out to be a big mistake.  We wasted a lot of time learning the platform on the fly and ended up having to do bunch of custom development work to make up for the lack of available module.  This experience has taught us caution.

My site runs in an older version of Drupal.  How will the release of Drupal 8 impact me?

It depends.

The Drupal community typically supports the two most recent versions of its platform.  When a Drupal version is supported new updates continue to be released that plug key security holes in the core platform.  Currently, Drupal officially supports Drupal 6 and 7.  Once Drupal 8 is released, versions 7 and 8 will be supported.

If your site is built in Drupal 7 you can expect Drupal core and key modules to continue to be updated for three to four more years.  So there is no pressing reason to move to Drupal 8 unless you are super anxious to take advantage of the new features.  I would advise you to look to migrate as part of your next site redesign.

If your site is running in Drupal 6 I would make plans to migrate to either Drupal 7 or 8 at some point in 2014, assuming security is a concern and your site is mission critical.  With the release of Drupal 8 you will officially be running on an unsupported version of the platform.  No new security patches will be released for Drupal 6 and modules will stop being updated, which means you will be vulnerable to security issues.

If your site is running in Drupal 5 or below this won’t impact you much.  You are already running an obsolete version of Drupal and exposing yourself to a variety of security problems.  The release of Drupal 8 won’t really change anything.

Giving Back

Support Some Great Charities

Our Brick Factory team was extremely fortunate in 2013.  We had the opportunity to do a lot of important work for great people.

As a small way of giving back we will be making donations to the American Cancer Society, American Red Cross and Wounded Warrior Project this holiday season.  But we need your help in deciding how to distribute the gift among these three amazing charities.

Click here to visit our holiday page and allocate a $2 to your favorite.

We will donate a total of $2,000, so vote today!

P.S. We work with a lot of great non-profits and charities ourselves.  We specifically chose charities with which we have no affiliation since it would be impossible for us to choose to donate to one client over another.

Update: Voting for the campaign is now closed.  We will end up donating $742 to the American Cancer Society, $558 to the American Red Cross and $700 to the Wounded Warriors.  Thanks to all who voted.

IE7 = Awful

10 popular websites that look awful in Internet Explorer 7

If you ask a web developer what they think of Internet Explorer they will probably tell you how awful it is in very colorful language.  If you ask them specifically about Internet Explorer 7 they will either burst into tears or punch you in the face.  You see, over the last four years that web developer is likely to have wasted hundreds of hours implementing hacks to make theirs sites work in IE7, which doesn’t support many modern web development techniques.  That pain runs deep.

It didn’t have to be this way.  IE7 was originally released in October 2006 and a new version hasn’t come out since April of 2009.  If it followed a normal adoption cycle it would have been forgotten years ago.  But due to some poor planning by Microsoft and the ubiquity of Windows, IE7 has shown amazing resilience.  Sort of like a cockroach.  IE7 maintained 5-10% market share for years after its last release.

Over the last year IE7’s market share dropped below 1% and developers finally feel free to ignore it completely.  However I still get the occasional client that requests IE7 compatibility.  As a way of helping make the argument against IE7 compatibility, I’ve made a list of some popular websites that look awful in Internet Explorer 7.  If these folks can completely ignore IE7, can’t we all?

(1) Tumblr

Signing up for Tumblr is a little challenging in IE7.


(2) Gawker

The entire Gawker family of web properties (Deadspin, Jezebel, IO9, etc.) look completely awful in IE7.  God bless them.



(3) Mashable

It should come as no surprise that Mashable’s cutting-edge, scroll-tastic design has problems in the ancient IE7.




You would think that a site operated by Microsoft as recently as last year would work in IE7.  Not so much.


(5) Atlantic

Like many, The Atlantic includes a note telling you very nicely to install a real browser.


(6) Salon

The IE7 version of the Salon website skips the whole site branding/navbar thing altogether.



(7) NBC News

Users of IE7 are probably quite used to seeing overlapping text like this.



(8) YouTube

Before you are even allowed to browse YouTube in IE7 you get a giant warning saying that your browser isn’t supported.  Site looks ok, with the exception of none of the video thumbnails being visible.



(9) Twitter

Twitter appears to be showing the mobile version of their site to IE7 users.




(10) Healthcare.gov

This one is sort of piling on, as www.healthcare.gov still functions pretty well in IE7.  But if you look at the screenshots below you’ll see the bottom half of the homepage is pretty different in IE7 when compared to Chrome.

Internet Explorer 7




1,000 programmers can’t fix healthcare.gov in a month

Like many folks in the DC web development community, I’ve been reading with interest the horror stories about the launch of healthcare.gov.  Just yesterday new revelations came out that showed just how complicated the site truly is and just how deep the problems are. 

As a web developer, my reaction to the situation is a bit different than most people’s.  I mostly feel pity for the people who built the site and who are stuck fixing the problem.  Now I don’t feel sorry for the management at companies like CGI Federal, who are likely getting rich off the site’s $174,000,000 price tag.  But I do feel sorry for the web developers that are in the trenches right now working to fix the site’s problem.  From experience, I can tell you they are in hell.

Based on what I’ve read, I’m also extremely pessimistic that the “tech surge” ordered by the Administration will get all the bugs with the site fixed by the end of November, as the Administration has promised.  

The truth is that throwing more resources at healthcare.gov isn’t likely to solve the problem, at least not in the short term.  The new developers and project managers brought in to help will need time to familiarize themselves with healthcare.gov’s source code.  Developers and project managers already sourced to the project will have to spend time training new folks instead of fixing the problems themselves.   The new resources brought on may actually slow things down initially due to the complexity of integrating them into the work flow. 

Perhaps the bigger problem with the one month timeline is that it assumes that healthcare.gov as it exists in its current form can actually be fixed.  Given its rumored 5,000,000 lines of source code, healthcare.gov could be a spaghetti code scenario that requires a complete rewrite. 

You don’t fix a site that has 5,000,000 lines of code by bringing in more people to write more code.  Human resources can’t be scaled the way servers can be.

The whole situation reminds me of this quote from computer scientist Fred Brooks about throwing resources at a project.


For the developers working on the project, I really hope healthcare.gov is stabilized by the end of November.  But based on my experience, I think we’ll be hearing about bugs on healthcare.gov for many months beyond November.  The people making that November promise are the same ones who gave the go ahead to launch a disastrously buggy site by October 1.