“Cool project, what CMS did you guys use?”
I recently worked on Pass223.com, a simple site that urges the Senate to pass a piece of legislation that requires the Senate to adhere to the same electronic financial disclosure rules in place for representatives and presidential candidates.
Pass223.com is similar to that of hundreds of related action sites: choose a legislator, call them, report results, repeat. I wrote the code, our esteemed creative director Kerry did the bulk of the design, and various others here at Sunlight helped to refine the concept and wording of the site and call script.
It was a bit surprising seeing how positive the feedback has been for such a simple site. A number of people have been pointing to Pass223 as an example of how this type of thing should be done. Most of that credit goes to the team that worked together to revise the awesomely straightforward script.
The other question that has come up is what content management system (CMS) Pass223 was done on and what legislative database it was built on top of. This made me think about the other reason Pass223 was able to come together the way that it did, the tools used behind the scene.
When all you have is a hammer…
It seems, especially in the nonprofit world where developers are sparse, that content management systems like Drupal are considered the solution to every problem that arises. Because Content Management Systems can not possibly do everything that organizations want they are left with two options: attempt to mangle the CMS to do things it was never intended to do, or alternatively not get what they actually want. Because of the difficulty in dealing with the massive codebases of most CMSs, they often find themselves accepting both results. A great deal of time is therefore sunk into a project and in the end things still don’t work quite how they were planned.
The supposed benefit of a CMS is the speed of deployment and ease of use, but as Jeremy’s recent post about LetOurCongressTweet mentioned, we are able to rapidly create sites without the use of a CMS. And in reality, struggling to fit an innovative project or idea into the rigid structure of a CMS is not easy nor fast.
A better use of the time and money spent maintaining and modifying complex CMS installations would be to spend that time learning and deploying sites in a framework such as Django“) or Ruby on Rails.
Perfectionists with Deadlines
Django in particular was created to solve this problem. Working with a bloated CMS forces you to make a decision between getting what you want and getting something fast, and more often than not you wind up with neither. It is because of this that a team originally working at the Lawrence Journal-World newspaper built Django to meet their needs as “perfectionists with deadlines.”
Frameworks like Django provide all of the pieces of commonly used functionality, user registration, Object-Relational mappers to avoid dealing with the database directly, caching, and a ton more. All of these pieces are given to you without any mandate that they must all be used, they are simply building blocks from which your particular project can choose to use or not. A large site such as EarmarkWatch may need complex user profiles, whereas it is possible to eschew all of the unneeded modules and build something as quick and simple as Pass223.com.
Ultimately, unless some CMS already provides exactly what you want, it is far easier to build a project from reusable components within a framework than to attempting to teach an old CMS a new trick. One of the reasons that Pass223.com seems to impress people used to looking at the typical contact-your-legislator forms is because we had the flexibility to build what we wanted.