All of this is to say that when we do take on a project outside the realm of the .edu world, we generally don’t stray too far.  We have recently finished a project for Creative Commons that, even though outside our traditional range, was a great fit for us, and let us try out some of our ideas in a new context.

Creative Commons’ ccLearn project is attempting to do for the world of education what Creative Commons itself does for creative capital in general: to democratize a closed industry by promoting open standards and the sharing of resources, while protecting the rights of creators and authors.  It is a really interesting project, that promises a substantial benefit to society; on top of that, it’s excitingly geeky.

What we were hired by CC to do is help convey ccLearn’s message to a wider public audience.   Currently CC is about as geek-friendly an organization as there is; certainly most anyone who uses technology on a regular basis knows who Creative Commons is and what they do.  But they don’t do too much outreach to the general, non-tech-savvy public; most of the public awareness of CC comes through its integration with sites like Flickr. And even Flickr’s CC info page is fairly technical in tone.

What that means is that in the general public awareness sense, CC works behind the scenes.  And for Creative Commons itself, that’s fine— much of CC’s work has to do with promoting legislation, defining open standards, and so forth, and it doesn’t require a large public profile.

But ccLearn’s mission is different— they plan to be much more directly involved with individuals seeking to produce or consume open educational content.  The fifth-grade teacher who can use open resources to supplement her class materials, or the program director looking for guidance in developing a poetry workshop: these are very concrete public audiences, and their awareness of open education resources will be of great importance to ccLearn’s overall success.

This means that ccLearn needs (to use a crude marketing term) a different brand positioning than Creative Commons in general.  Our job was to help them find that place, and interpret it visually on the Web.

ccLearn currently lives at http://learn.creativecommons.org.  This site serves as the base camp for ccLearn’s internal operations, such as its board members, top contributors, and other stakeholders, and it shares a general look and feel with Creative Commons.  Our first recommendation to CC was to create a separate URL for promoting open educational resources to the public:

opened.creativecommons.org

And with that new URL came a brand:

(The follow-up text is still in flux, as ccLearn decides how best to position Open Ed with regard to CC.)

As part of our messaging strategy, Donald wrote a couple of opening sentences that neatly encapsulate ccLearn’s offering in a way anyone can understand, geek or not:

“Open education brings the ideas behind open source to the world of education. Open ed resources are learning aids, reference materials, and even textbooks that are free to use and free to distribute— whether you’re a teacher, a learner, or a little of both.”

(This kind of friendly, just-the-facts introduction is a particular talent of Donald’s— he wrote opening paragraphs for Southwestern and White Whale’s 2007 site.)

And finally, we created a site design:

… that will allow ccLearn to put a wide variety of engaging content in front of a relatively non-tech-savvy public, while allowing them quick access to basic information about open education and without turning off insiders with “marketing”-ish language.

We handed off the final files, including XHTML/CSS/JS buildouts of the homepage and inside page templates, to CC this week; they’ll be doing the implementation with their wiki-based CMS.  Overall we think it’s a great success, and we’re happy to know they think so too.

To view the buildout version of the site, visit http://opened.babywhale.net.   To view Donald’s buildout handiwork, I suggest you try it without Javascript and/or CSS.  Oh, and click into the search box!

I recently looked at five versions of a free class that provided some relatively trivial functionality that I wanted to include in our CMS, but didn’t want to spend too much time with. Some of them felt like they were the size of our entire core CMS library! I found plenty of frills that we don’t need (bloat which arises when a developer wants to pack their project with features to make it more than it needs to be), inefficient repetition of constants, and long procedures meant to do something that can be done in a few lines of smarter code (often meaning the developer missed some of the basics of the language). The fact that there’s a lot of garbage out there doesn’t imply that there’s nothing to gain by sharing open source code. In this case I had to study the scripts that I saw and develop my own (small) derivative, but if you are selective and critical when choosing to go with packaged code, there’s a lot of milage you can get out of other developers’ work. Fortunately, projects like PEAR (http://pear.php.net/) help to screen and collect useful code libraries and facilitate their distribution. Many other code archives just don’t fare so well.

I find that good PHP code is relatively fast and easy to write for any situation, because PHP comes with a wide range of libraries that automate most desired tasks, and the APIs are usually not very verbose. The places where I think open source software really becomes a feather in PHP’s cap are the multitude of extensions developed for the language as distinct open source projects (whether originally created for use within PHP or not). They are endless, and many of them are perfectly critical to writing a good web application. Nevertheless, there are areas where open sourced PHP code is also useful in the industry. I have felt that templating and caching are good examples of this, and created two open source projects for that. I aim to release another one that is designed to produce a powerful XML toolkit by adding a thin API on top of PHP’s XML foundation that vastly reduces the complexity of XML-generating code, making it more accessible to programmers at all goals and skill levels.

Some of the tools we have developed in-house and make freely available to whomever wants to experiment with them are available at http://technologies.whitewhale.net.

Maintaining code libraries does not have to contribute to bloat, either. The idea of a framework is to implement core APIs that are used from project to project to build functionality specific to that job. The independent framework itself will not absorb any of this site-specific functionality, contributing to bloat. A good framework plateaus, only growing incrementally upon necessity and relevance to the entire breadth of your work. Furthermore, more robust frameworks are modular, loading on the components they need. Sometimes explicit control is desirable, in which certain users are authenticated and given access to particular modules or plugins. Other times code logic dictates which portions of the framework need to be loaded and deployed. It may be desirable to go for a model in which services are dynamically registered within mechanisms central to the framework.

It’s particularly exciting to be in a position where you can rely on a powerful foundation of tried-and-true code, and be free to unleash your creativity in terms of how those static APIs are deployed from project to project. Broader communities might also benefit from your work if you can isolate and open-source particular APIs that contribute to smart application development, and certainly there are great options out there which you can adopt and benefit from yourself. Just as with any other career, the knowledge you gain, tools that you build, relationships that you make, over time, help to define who you are and what you can bring to the table in terms of problem solving, creativity, and commitment to the industry in which you work.