Compass Screencast

I've put together a screencast that demonstrates how to get up and running with compass and use it to style a basic webpage. It covers some basic sass syntax in case you're not familiar with it, and then shows how you can create a stylesheet for your semantic markup. If you've been skeptical of the value that compass and sass provide, hopefully seeing it in action will convince you!

The Open Source Project that Social Media Made

I realized recently that my open source project, Compass, has become popular enough to consider it moderately successful. It has a community, I get bug reports and patches. People write blog posts about it without prompting. I've been asked to give talks about it. All those benefits that you tell your company they will get when you release something into the wild, but that rarely actually happens. It occurred to me that the history of how Compass came to be is actually the story of how social media can make and shape a software project. So I thought I'd share that history with you.

Github

My friend Dustin turned me onto github when it first launched. Suddenly the bar to release open source software had lowered to the point where it was easy enough to share code without putting much effort into project hosting. In those first few months I threw almost a dozen projects up. Finally, I could give back to the community almost as easily as I could take. It was addictive. Every new watcher was a glorious moment. One day, after porting the blueprint css framework to sass, I decided to throw that up there too. It was only about 8 hours of work, maybe less. I wasn't nearly as proud of it as some of the other projects I released. But I thought I might be able to save someone from having to do their own port. This project was called "blueprint-sass" and I still keep it around as "Github SEO Strategy." Within a couple weeks, this project had attracted more watchers than all my others combined. I knew I had struck a nerve but I wasn't really sure how to proceed.

Blueprint

So I took my case to the age-old social media forum that is the Newsgroup. I suggested to the blueprint mailing list, that my new stylesheets built in sass should be the blueprint core stylesheets and that what they generated could be the blueprint distribution. And that those who wanted to use the sass stylesheets directly, certainly could. This seemed (and continues to seem) like the best way to manage that code base, since maintaining a port to a different language is a lot of extra work. I got a green light to begin work on a blueprint proof of concept based on sass which I threw myself into with full gusto. Many of the blueprint tools became obsolete because the sass stylesheets could perform programmatic calculations and sass has several output modes. Before I knew it, except for the generated css that came out, this was a whole new project. The scope of the changes ruffled a few feathers, I guess, and so it was decided that my code wouldn't be merged. As sad I was about this outcome, I was very proud of what I had built and the quality of my code was certainly a reflection of the expectation of becoming part of one of the most watched projects on github. I was not to be deterred in my efforts by this set back. In retrospect, it was probably one of the best things that could have happened.

Heading Off in a New Direction

While coding my port of blueprint, it occurred to me that so much of what I was building had little to nothing "blueprint specific" about it. The tool set was basically generic, change the Sass stylesheets and you could have a new sass-based framework. Now anyone who knows me can tell you that I love meta-ness. And since programming and software archicture is what I do best -- not actually devising clever css frameworks -- I thought I should stick to what I know and provide a tool set to css frameworks and the users of those frameworks everywhere so that they could take advantage of the real star of the show: Sass. Someone needed to point them all in a new direction: A new way of creating and sharing design from the geniuses of the web design world to the mere mortal web developers (like myself) who are much better working on someone else's design than coming up with our own. And so the two-fold vision of providing a compelling library to promote the use of Sass and to bring to web design the concept of sharing code was born. I gave it the name: Compass. Even today my vision for what compass should be is not yet fully realized. But I'm down to my last few unimplemented features before I can declare it version 1.0.

Guerrilla Marketing via Social Media

A wise man once said, "Don't worry about people stealing your ideas. If they are good enough, you'll have to cram it down their throats." (I wish I knew who to attribute that to, I think I heard it in a TED talk). As I was building Compass, I knew from my experience with blueprint, that if my idea was actually a good one, it was one of those requiring cramming. So I kept an eye out for social media opportunities to market it. If an article on CSS or especially CSS frameworks showed up on reddit, digg or ycombinator news, I found a way to link to my project in there. I left comments on relevant blog posts. I eavesdropped on twitter for people talking about blueprint and css, and pointed them toward compass. Week by week, compass grew. Compass-style.org got "stumble-upon"-ed. A small but fervent community of early adopters saw what compass and sass could do for web development, and they latched on to it. They blogged about it, and they tweeted. Oh my did they ever tweet. It's just so damn easy to send out a link to a new and exciting technology and thanks to the large number of ruby developers on twitter who are always eager to try new things, compass spread quickly.

Collecting Feedback via the Twitterverse

Twitter was instrumental in my ability to communicate directly with my users or potential users and learn from them. I learned from their reservations, and I learned from their criticisms. Their positive feedback gave me the energy to keep going. I was able to find out about and fix bugs within hours instead of days. My tech support responses came back to folks asking the twitter-void for compass help. Before twitter, those might have been users who gave up before completing their initial evaluation.

My Commitment to an Open Project

An open project means much more to me than just being open source. An open project is one that is conducted transparently. Compass is here in the form that it is, because it is what is needed. It's solving real problems for folks today. I know this because they told me through their actions on social media sites like Github and Twitter. But Compass can be much, much more than it is right now. Compass and Sass can change the way we think about the implementation of website design. I have a vision of a future, but I want to work with all of you to make sure it's the right one. I'm listening to your feedback and thoughts and acting on them. I know that a large part of the success of Compass to date has depended on that conversation, and I intend it to continue. Compass is nothing in the long run without its community and I look forward to fostering it more in the coming years.

The Names You Give to Your Data Models Matters More Than You Might Think

Early in the days of Caring.com we planned to build a personal homepage for our users that would delight them with a customized selection of content that was appropriate for the issues they were dealing with. Many of our early architectural decisions centered around this premise. Unfortunately, the breadth and depth of our content was not sufficient to support that feature and it was shelved rather than disappoint our users. Almost two years later, we have an amazing selection of content for the most common care giving issues, a small army of experts waiting to answer care giving questions from our users, a small but active community of caregivers that are helping each other get through some of the most difficult times of their lives, and a comprehensive guide to care giving resources in your area. We are finally ready to personalize our site and deliver what we hope will be delightful experience for those people who choose to fill out a short questionnaire (not yet launched at the time of this writing).

So I got to take some old code off the shelf and dust it off. It was exciting, and a little frightening. In those early days, I knew I needed a model to represent the person or people that our user is caring for. With my overly analytical, highly trained engineer brain and no formal education in geriatrics or care giving, I called this model the CareTarget. That name stuck, and from time to time, I'd hear myself and others refer to the care target when we needed a term to use in conversation. And while this name clearly and unambiguously describes the purpose of the model, it was the wrong term. These are people, not targets. They are your loved ones and they are my parents. I felt the term CareTarget was dehumanizing. These are the people who receive our care, because we love them and because they deserve it. They are a CareRecipient. Sitting alone in my office, with deadlines to hit, I decided that I could not allow this term to persist. In two weeks the number of uses of these names, would double or more -- there was no better time to rename them than right then, and so it was done right then. Similarly, a model called CareTargetType was changed to CareRelationship (E.g. Mother, Father).

When I came to scrum (our daily standup meeting) the next day and announced I had made no progress on my tasks, not everyone understood why the change was so imperative. But these names are at the very heart of what Caring.com is and does, nothing that central can be allowed to be wrong. Not even their names. In total, I spent a day and a half renaming what were arguably fine names -- they needn't have ever been exposed to our users, but now I never have to worry that they might. And in a few months, when I hear folks in the halls of Caring.com talking about the care relationship one of our users has to their care recipient, I'm going to smile because I understand that the names in our code have a real and lasting effect on the tone and understanding of our domain. Software Architecture and Design is most certainly a technical field, but that doesn't mean it has to be dry and impersonal.