How to Get Open Source Project Ideas and Execute Them

A common question people ask me is how I come up with open source project ideas. It is a pretty simple process:

1. Have A Problem
If you are a developer, when you are building stuff you will have to solve problems. On top of those, as a human being you will have problems every day. How can I share responsive web design examples to educate my clients? How can I make a more flexible grid system for responsive web design? How can I help my kid learn his ABC’s? Are my passwords manly enough?

The first thing most of us do is see if that problem has been solved before, and how. It may be that the problem has been solved effectively, and there is no need for you to solve it again. Many times, there are different approaches to solving the problem, but none that work quite the way you’d like. On rare occasions, you have encountered a problem that doesn’t have any good solutions yet, which can be quite exciting.

1a. Come Up With a Cool Name
This is probably the most fun part of the process, haha. Cool names are cool!

2. Solve The Problem
Get on it. Solve that problem. It could be that solving a particular problem is too large and ambitious to pull off. Either find some friends to collaborate with, or break the problem into smaller components then go after them one at a time.

3. Abstractize Your Solution
When possible, craft your solution in such a way that it can be applied more generally, for people who encounter the same problem.

4. Publish
Throw it on Github, of course, but if you want your project to stand out, go the extra mile. Make a great demo page to showcase your project with some clear, easy-to-follow documentation.

5. Don’t Be Shy
If you release a Github project in the woods, does anyone notice it? To get your project noticed, you need to publicize it. Tweet it out and share it up. Send it off to newsletter publications (e.g. JavaScript Weekly, HTML5 Weekly, etc.) Even better, create a tutorial and try to get it published online somewhere like Codrops, Tuts+ or Smashing Magazine.

6. Repeat
The more you projects you publish, the more ideas you will have. I recommend maintaining a list of your project ideas on Google Drive or Trello.

Awesome Responsive Screenshots


Below is a quick, simple way to generate screenshots of Responsive websites like this (note: link is a big image, so it will take a while to load).

Go to the Responsivator website and enter the url of the website. Check the hide header option. This will generate you a url like this:

Go to that url and use the Capture Webpage Screenshot Chrome Extension to take a screenshot. After a few seconds of processing time, you will have yourself a nice looking screen capture of your website across a variety of screen sizes (like this).

If you’d like to customize the screen sizes, click the customize button in Responsivator and adjust the frames settings

Note: This article has been updated since originally published. The tool previously recommended is no longer available (as you may notice in the comments).

Extra Strength Responsive Grids

boxYesterday, I released Extra Strength Responsive Grids, the latest open source project from the devs at Draftfcb Chicago. It was a collaborative effort between myself, Tim Svensen and Andrew Pulley.

Some of you may be thinking, “Just what the world needs, another CSS grid framework.” People understandably are asking me what makes this approach different.

Well, it isn’t really all that different from other grid frameworks you may have come across. It shares similar functionality to responsive grid systems like Zen Grids and Profound Grid in that it makes heavy use of media queries to allow for great layout flexibility.

Where it differs is it adds its grid classes to the markup, rather than the css (or scss). I prefer this approach because I find it to be self-documenting and expressive.

What I mean by ‘self-documenting’ is that I can look at the markup and immediately understand the layout behavior, without having to search through css (or scss) files. I don’t have to try to remember which class has which mixin or inherits from what.

I find it to be more ‘expressive’, because I can add or change these classes around to quickly change layouts on the fly. I do a lot of prototyping, and I’ve found this system to work great for that.

Now, that isn’t to say there aren’t drawbacks. You can wind up with a lot of divs. You will be using non-semantic classes. Other grid systems adhere more closely to OOCSS principles. For me though, I keep my grid/structure classes separate from the content classes. I let the grid do what it is supposed to do, and construct the scaffolding for the page. Then, I create the content ‘modules’ that have their own css to describe how they occupy their container (their grid). When I’m building out my widgets and so forth, I try to stick to OOCSS principles.

To sum up, I think of content as ‘objects’ and the page as scaffolding for those objects.

This is my current approach, but I don’t expect it to be right for everybody. In the future, I may change my mind and do things differently. As front end web developers, we must always be re-evaluating our craft.

Responsive Experiments

It seems like everybody working on websites these days is experimenting with various responsive web design approaches. There’s the Filament Group’s Compressive Images. There’s Luke W’s relentless exploration of mobile ui patterns, the pace of innovation. You have Brad Frost’s rapidly growing list of This Is Responsive Web Design Resources. The amount of work being done on Responsive Images alone is off the charts.

I’ve been experimenting as well. For instance, tables are another thorny problem when doing responsive. How do you translate those wide data tables into a narrow screen? Zurb’s Responsive Tables is one potential solution. On a project, a creative director I was working with had another idea, and I decided to give it a go.

The result is stacktable.js – a jQuery plugin for transforming big wide tables into skinny tall tables. It works by creating a duplicate table, with all the key/values arranged vertically. Using a media query, you toggle which table gets displayed. Check out the project page for a demo, and the code is on Github (of course!). This is more of an experiment at this point, so I’d love to get feedback.

Another experiment I have is an approach that I call Responsive Viewports. It isn’t something I’d recommend generally, but it can do in a pinch, when something is better than nothing. It works when you have a fixed width layout for screens above a certain breakpoint, and a fluid layout for screens below that breakpoint. Using the viewport meta tag, you can tell the browser to zoom to the appropriate size for your fixed width layout, and to scale to the device width for the fluid layout. You put some javascript in the document <head> to detect width and set whichever viewport is appropriate. Here’s the code:

The web is a challenging environment. The pace of change is relentless. Some might even say scary. I’d say it is exciting. The web demands innovation and that’s why I love my job.


Responsive Web Design is pretty darn cool, but it is hard sometimes for people to wrap their heads around it. Whether you are trying to share a cool responsive website or do a creative review, telling people to change their browser window size just doesn’t cut it. With that in mind, a few weeks ago I created, open sourced and released Responsivator!

There are plenty of viewport testing tools out there (apparently even including one named Responsinator) but none that worked quite the way I wanted

First, I didn’t want their to be ads. Even better, I wanted a way to show these websites with no clutter at all. With Responsivator!, you can do that. Just add the hide header option to the end of the url, like this:

Also, it is possible to customize the sizes and frame labels that get displayed. For example, if you only want to show the phone sizes of a website, you can do this:×480:Phone%20(portrait),480×320:Phone%20(landscape).

As one of the first projects released on my developer group’s Github account, I’m very please to see that based on the traffic stats, it is a huge success. After the initial burst of popularity due to getting to the front page of Hacker News and a nice article on Webmonkey, it continues to get about 500-1,000 page views a day. You can expect to see a lot more cool projects come out from us in the upcoming year.