Monthly Archive for March, 2009

Join Us at Web 2.0 Expo

Published by alon on March 31, 2009 in Agile. 0 Comments

Maria Giudice from Hot Studio and I are following up our Core Conversation at SXSW last month on agile development and human-centered design with a panel Thursday at 11am at Web 2.0 Expo in San Francisco titled Can’t We Just All Get Along? Human-centered Design Meets Agile Development.

Our panel includes Arena Reed, Lead User Experience Designer at Grockit, Rob Spiro, co-founder of Aardvark and Dave Shih, Senior Visual Designer at Hot Studio.

At SXSW Maria and I realized how easy it is to talk about the challenges of coordinating design and development efforts since almost everyone involved in software development has experienced some pain around it. I’m excited about our panel for Web 2.0 Expo because I think we are going to better organize the discussion around identifying best practices. I am particularly inspired by the work of the Aardvark team who are intensely user-focused and test like crazy to validate their ideas and implementations while maintaining an agile software development process with frequent incremental releases.

You can follow our panel on Twitter with hashtag #agileux20 even if you are not at the conference. We welcome comments, questions and suggestions before, during and after.

SmartyCard Launches!

Published by don on March 18, 2009 in Clients, Flex/Flash and Java. 0 Comments

Our client SmartyCard launched in early March at the DEMO conference picking up the People’s Choice Award.  SmartyCard is a learning site that offers kids rewards for completing a variety of interactive learning games.  Kids are able to ‘learn, earn and play’ grade-appropriate games while earning real and virtual rewards.

Agile Modeling Techniques for Story Writing

Published by rob on March 12, 2009 in Agile and Software Design. 1 Comment Tags: , , , .
At Carbon Five, all our projects begin with ‘customer facing’ meetings focused around determining scope and expectations. A core component of these early meetings involves one or more story writing sessions. The end goal of story writing sessions is to have most user stories in a project documented (i.e. in Pivotal Tracker) regardless of whether you have a requirements document or not. Story writing sessions are informal and conversational in nature, where information from customers are digested by a Team Lead and converted into stories. Most of the time, I compile user stories as a linear list in Tracker (displayed on the wall using a projector) while discussing functionality with a customer. However, sometimes customers have a difficult time ‘connecting the dots’ because of the linear nature of a list.       

On those occasions, I supplement my list in Tracker with another technique for capturing user stories. It involves modeling using a UML IDE. Primarily, I use Activity Diagrams because they capture behavior using ‘actions’ and allow for flow. Because activity diagrams are essentially flow charts, they provide a simple comprehension mechanism for all customers regardless of their technical background. I usually display my desktop in the conference room using a projector and interactively add elements to the diagram as I receive customer input. For demonstrating modeling techniques, I will use a ‘Music Store’ web application as an example.

Summary of Steps:

  1. Create an Activity Diagram from a High-Level Functional Requirement.
  2. Capture Customer Input for Identified Functional Requirement.
  3. Model Flow for Activity, Link Actions with Diagram Elements.
  4. Aggregate Similar Actions to Separate Activity.
  5. Convert Activity Diagram into User Stories.
  6. Repeat Steps until all Functional Requirements are Exhausted.

Step 1: Create an Activity Diagram from a High-Level Functional Requirement

Start with a known high-level functional requirement and create an Activity diagram. When starting, I will identify a large chunk of functionality that I know to be required for the project and use that as a discussion point with the audience. For my sample Music Store project, I would choose ‘Browsing the Inventory’ as a large piece of functionality. At this point, the audience might begin to shout out other large pieces of functionality (i.e. ‘Customers can create accounts’, ‘Employees can add to inventory’). If this occurs, I like to create empty Activity diagrams named appropriately. These large pieces of functionality will eventually be decomposed into smaller, more manageable, Activities and Actions.

 

High-Level Functional Requirement as an Activity

Step 2: Capture Customer Input for Identified Functional Requirement

Gather input from the audience regarding this Activity / functional requirement and capture pertinent information as Actions. Essentially, what you are trying to do here is decompose the larger ‘Browsing the Inventory’ functional requirement into smaller ones. Make an attempt to name each of the Actions with story-like syntax (i.e. ‘As a <role> I can <result> so that <benefit>’). The goal of this step is to create a catalog of smaller functional requirements so that you can start modeling flow.

Capturing Smaller Functional Requirements as Actions

Step 3: Model Flow for Activity, Link Actions with Diagram Elements

Start modeling flow for this Activity, linking Actions with other diagram elements. All Activities must have a start as well as an end point. I model my Activities so that my flow is complete. This ensures that all known paths have been captured. This step is crucial in capturing all known functionality for the high-level requirement.

Remember that this is an interactive step with the audience. The audience / customer will provide input as to the flow of the Activity from Action to Action.

Adding Flow to Activity

Adding Flow to Activity

Step 4: Aggregate Similar Actions to Separate Activity

If the diagram begins to flow outside of your viewable area, this is an indicator for breaking out one or more actions into a separate Activity. Several actions can be converted into one abstract action that encompasses all the functionality provided by all those actions. In the figure in step 3, the Action ‘Purchase an Item’, was created to represent another Activity diagram. The separate Activity diagram that I created was named ‘Purchasing an Item’ and contains the detailed flow for that functionality.

This step is reliant on the Tech Lead’s skill to identify similar areas of responsibility within the activity. 

Step 5: Convert Activity Diagram into User Stories

After one Activity diagram is fairly complete, begin entering them into Tracker as Stories. Each Action should be converted into a user story using a consistent syntax (i.e. ‘As a <role> I can <result> so that <benefit>’).

 

Convert Action elements into User Stories

Convert Action elements into User Stories

User Story list with Activities as Milestones

User Story list with Activities as Milestones

 

Step 6: Repeat Steps until all Functional Requirements are Exhausted

Steps 1-5 must be repeated until all high-level functional requirements have been modeled as Activities during discussion. In the end, I will have a catalog of Activity diagrams. In the figure below, a Package Diagram displays all the Activity Diagrams that I have modeled. I like to use each of the Activities as a milestone during planning. This may or may not be ideal depending on how granular your functional requirements are.

Inventory of Activities as Milestones

Package Diagram: Inventory of Activities as Milestones

 

Conclusion

There are many arguments against modeling in the agile communities, so it is important to view modeling as being supplemental to the process. In the end, our models are used to aid in the process of conveying and gathering information with the customer. Some other benefits include:

  • The diagrams can serve as a documentation deliverable
  • Interactive modeling along with the diagrams, which serve as a visual aid, improves customer comprehension of our software development process
  • This is a great way to capture requirements when none exist
  • The Activity diagram allows us to write stories in a format that follows an accompanied wireframe (if available)
  • User roles can be added to Activity diagrams as swimlanes (partitions). This aids in separating functionality by use case

Convenient CSS and Javascript in Ruby on Rails

Published by andy on March 8, 2009 in CSS, JavaScript / AJAX and Ruby (on Rails). 2 Comments Tags: , , , , .

I get tired of hunting through a hierarchy of folders and files, from the views to the public folder, to locate a certain CSS or Javascript file. It’d be convenient to have them right with the markup, but embedding these definitions within your HTML markup is a bad idea for several reasons. For our current project, I proposed we put everything in the view directory so they are easy to find:

app/
  views/
    home/
      index.html.rb
      index.css
      index.js

The convention is clear: to add page-specific CSS code, just create a new file with the same name as the view, in the same folder. Easy to add, edit and remove. The alternative (using the public folder), usually leads to a parallel hierarchy and the inconvenience of that.

I also thought, that this being Rails and all, the files should be included automatically. It turned out to be pretty easy. Continue reading ‘Convenient CSS and Javascript in Ruby on Rails’

When Worlds Collide: Conversation with Maria Giudice of Hot Studio

Published by alon on March 5, 2009 in Agile. 4 Comments Tags: .

sxsw09

Maria and I have already started our SXSW Core Conversation When Worlds Collide: Human Centered Design Meets Agile Development two weeks before the event in Austin. The Core Conversation format is a speaker or two in conversation with the audience. Below we respond to a few select questions.

About the Presenters

Maria Guidice is CEO and founder of Hot Studio, a human-centered design studio in San Francisco.
Alon Salant is a principal and founder of Carbon Five an agile software development firm also in San Francisco.

Our companies have worked together over the years on a number of successful projects. We find our collaboration continually challenged by the differing perspectives of designer, developer and client. We love working together and are always looking for ways to do it better.

We Want to Hear From You

Join us for this conversation in Austin Sunday, March 15, 3:30-4:30pm. If you can’t make it, we have created a Google Moderator series to solicit questions from you. Please vote for questions you like and/or add questions and topics that you think we should discuss. Alternately, ask questions as comments to this post. We want to hear from you.

Let’s Get Started

Why is the issue of waterfall vs. agile so emotional for design and engineering teams?

Alon: We all work hard to do the best work we can for our customers. Software developers have struggled for years with the mismatch between heavy-weight planning processes, the ideal world they are based on, and the messy work of getting software built in the real world. Agile software processes provide an approach that deals very well with the real world while retaining strong professional rigor.

Committed agilists bristle at approaches that do too much planning for too far in the future. The further out you plan the more inherent uncertainty there is and the greater the chance that you are wasting energy on speculation.

For designers I think you can flip this argument around. If you start building something without knowing what you are building there’s a good chance you build the wrong thing and have wasted all the time and effort you put in to it.

Obviously there’s a middle ground somewhere. It turns out to be surprisingly hard to find.

Maria: I think the reason that this issue is so emotional goes to the very core of the fundamental difference in the way designers and engineers think about design.

The waterfall process affords designers the time and space to learn about the problem and craft a solution based on insight from understanding human needs, wants and desires. They then can craft a plan of action based upon big-picture thinking and strategic insight. From there they can be specific about details and functionality based on how the system works contextually.

The agile process oftentimes does not afford designers the time to think and requires them to design details out of context. This way of working puts them at great unease and anxiety that they are designing things based on hunches rather than validated user research.

Engineers, however, feel very comfortable working at a detail level that can be changed (theoretically) later on and can build towards a functional product sooner rather than later. Engineers may not understand the need or value to spend the time upfront—”why not jump in early if you have the freedom to change your mind?”

Think of the two processes like carving in marble vs. building in clay. It can be very difficult to switch design mediums they have worked on their entire professional life.

What is your greatest satisfaction when working with designers?

Alon: Designers have the gift of being able to represent ideas and solutions visually, in a form that all stakeholders in a project can understand and respond to. A designer can engage business owners and developers in a conversation about product requirements, priorities and potential solutions then turn that into a visual representation of one or more solutions. The visuals create a level playing field and focus the attention of all participants in a project. I love the role of designer as facilitator.

What is your greatest satisfaction when working with engineers?

Maria: We look to work with engineers that consider themselves equal contributors to the design process. Hot Studio is lucky to work with the folks at Carbon Five for this very reason. Too often designers view engineers as builders of “their product” and they miss the value of thinking about a design problem from an entirely different mindset. Great engineers understand the value of human-centered design and are active participants and contributors throughout the design process. Great engineers bring to the table that unique perspective that does not focus on limitation, but one of unique possibility.

What is your biggest point of frustration when working with designers?

Alon: Many designers, particularly user experience designers, feel they need to understand a problem in both depth and breadth before they can create meaningful solutions. Even when a project schedule and budget allow for up front research too often it is not enough for the designer and they feel they are working with incomplete information.

Projects can rarely afford exhaustive up front research and I get frustrated when designers use this as an excuse instead of coming up with an alternative approach.

I would like to find a design approach that could use some research up front to set a strategic direction and then break up a large problem into smaller problems to be tackled incrementally. Ongoing research could continue to be a part of the design process, conducted incrementally as the next problem to solve comes in to focus.

What is your biggest point of frustration when working with engineers?

Maria: I have worked with many engineering teams over the years, and like designers, they can come in many different flavors. I get frustrated when engineers focus on limitations, not possibility. When design thinking becomes limited to meet a tight budget or the need to jam as many “features” into a product based upon a set timeline, you run the risk of prohibiting “out of the box thinking” that can have an adverse effect on maximum customer experience. What some engineers may think the experience is “good enough”, designers may conclude that “no it isn’t”. This is a big point of frustration for designers regardless of the problem they are trying to solve or the process they are working within.

What will people come away with after attending our core conversation at SXSW on March 15th?

Alon: Our conversation will give people insight into issues in the collaboration of designers and developers and ideas about how to work together better. It is an opportunity for attendees to learn more about human centered design and agile software development and to challenge our ideas on those subjects.

Maria: I think people will come away with thinking that one size does not fit all. Follow a process, whether it’s waterfall, agile or a hybrid between the two, based on the type of project, the team dynamics, and the client’s need.

Can we all get along?

Alon: Sure. But it may be harder than we think. For this collaboration to be truly successful designers and developers need to better understand each others’ priorities and fears. It’s too easy to sit back in your own world view and say, “They don’t get it. If they did they’d do things my way.”

Maria: Absolutely. It really comes down to respect, empathy, and good communication from the client, to the designers, to the engineers. To quote the critically acclaimed “High School Musical 2″ film—”We are all in this together!”

Together, as design collaborators, we can produce great things together and hopefully, have a positive impact in people’s lives.

Continuous Integration and Build Promotion

Published by christian on March 4, 2009 in Agile. 0 Comments Tags: , .

We have a build server and we practice continuous integration on all of our projects. In fact, it’s pretty much the first thing we set up after version control. We’re feedback junkies. It became especially apparent while working on a client project last year where we used their development infrastructure. They had a build server running, but the problem was that it took too long to get feedback. I was lost and jonesing. They had a monolithic build that took about 45 minutes to run its course and give me the affirmation I was seeking.

While setting up my current project, I decided to take a different approach when configuring our build server and continuous integration. I had a few goals in mind:

  • Super fast feedback
  • “Promoted” builds get pushed to the acceptance server
  • Minimize issues with the build infrastructure

I split our build into three plans:

Continuous Integration Build Plan

This resets the unit test database (using c5-db-migrations), compiles the project, runs all of the unit tests, and if there are no errors or failures, produces a war. The war is installed locally using Maven so that it’s accessible to other processes in a known location. This build is very fast and is triggered on every subversion commit. The command used for this build plan is:

mvn db-migration:reset clean install

Functional Tests Build Plan

This resets the functional test database, deploys the war built during the continuous integration build to tomcat using Cargo, runs all of the functional tests, and shuts down tomcat. This build is triggered on every successful continuous integration build (i.e. as a dependent build). A very short script performs the work of this build:

mvn -Pdev db-migration:reset
cd functional-tests; mvn -Pdev clean test-compile cargo:start surefire:test cargo:stop

And here’s the cargo-maven-plugin configuration:

<plugins>
...
    <plugin>
        <groupId>org.codehaus.cargo</groupId>
        <artifactId>cargo-maven2-plugin</artifactId>
        <version>1.0-beta-2</version>
        <configuration>
            <wait>false</wait>
            <configuration>
                <deployables>
                    <deployable>
                        <groupId>com.acme</groupId>
                        <artifactId>acme-web</artifactId>
                        <type>war</type>
                        <properties>
                            <context>acme-web</context>
                        </properties>
                    </deployable>
                </deployables>
            </configuration>
            <container>
                <containerId>tomcat6x</containerId>
                <zipUrlInstaller>
                    <url>http://www.apache.org/dist/tomcat/tomcat-6/v6.0.18/bin/apache-tomcat-6.0.18.zip</url>
                </zipUrlInstaller>
            </container>
        </configuration>
    </plugin>
</plugins>

Deploy to Acceptance Build Plan

This step doesn’t build anything or run any tests, but is a little more complicated than the others because it’s interacting with a another machine: our dedicated project acceptance server. We scp the war (built during the continuous integration phase) to our acceptance server. Next, we shutdown tomcat and clean a few things up (logs, old webapp, and work). Then we migrate the database (no reset because we care about the data). Last, we bring tomcat back up with the new war. This build is triggered on every successful functional test build. Here’s the script that’s run by the build server:

ARTIFACT_NAME=./ROOT.war
 
# SCP Application and Scripts
WAR=`find ~/.m2/repository/com/acme/acme-web -name "*-*.war" | sort | tail -1`
echo "Copying $WAR to acceptance server."
scp $WAR acme@acme-acceptance:$ARTIFACT_NAME
scp ./bin/*_as.sh acme@acme-acceptance:.
 
# Shutdown and Clean Tomcat
ssh acme@acme-acceptance sh ./shutdown_as.sh
 
# DB Migration
mvn -Pdev db-migration:migrate -Djdbc.host=acme-acceptance
 
# Install Application
ssh acme@acme-acceptance mv $ARTIFACT_NAME ./apache-tomcat/webapps/
 
# Startup
ssh acme@acme-acceptance sh ./startup_as.sh

Conclusion

This has worked out really well for the project and we get feedback very quickly.

You may wonder why we broke functional tests into their own plan. I find that functional tests can be a little less stable than unit tests (especially if selenium is involved), and they run much more slowly. I’ve seen cases where flaky functional tests caused a team to start ignoring build results because it was usually a problem with the infrastructure, not with the code. So, the decision was somewhat defensive and in retrospect, probably unnecessary.

We’ve spent less time maintaining our build plans than in the past as well. At some point, our build server MySQL instance crapped out and even though all of the databases were deleted, our builds all ran successfully when the build server came back up because they start with a database reset, which creates the target database and migrates it to the latest schema.

A single war is promoted as it passes a greater level of testing, and is eventually deployed to the acceptance server if all of the tests pass. While we’re saving a little time by not rebuilding the archive for each plan, that’s not the only thing I like about it. It just feels a little more right and it completely eliminates the chance that something about the artifact changes as it makes its way through the pipelines. The same war can make its way from the first CI build all the way to production. This is possible because we include default configuration for the application which matches our development environments, and then provide a mechanism for externalizing application configuration for the one-off environments.

I think most modern build server software provides everything you need to do something like this as it’s rather straight forward. However, for those who are curious, we have been using Bamboo for the last year or two and recently installed TeamCity so that we can give it a proper try. Both are great products, and if you’re on a smallish team, TeamCity is completely free (and is superior to the open source alternatives, IMHO).

How are you using your build server?

Proud to Support the San Francisco Bike Kitchen

Published by alon on March 2, 2009 in Uncategorized. 0 Comments

This week the San Francisco Bike Kitchen opens its doors at its new location in the Mission at 650H Florida Street. The SFBK is an entirely volunteer run organization that provides the tools, parts and instruction you need to fix or build a bicycle yourself.

Carbon Five is proud to be a Titanium Sponsor of the SFBK and a supporter of their efforts to keep San Franciscans safely commuting and playing on their bicycles.

Read more about the SFBK’s plans for the new shop space and the recent move from their downtown location entirely by bike trailer in the rain. SF StreetsBlog’s coverage of the move also provides a good overview of the history and mission of the organization.

We chose our office location in downtown San Francisco so that our staff in the city, south, east and north bay could commute to work without driving. We get to work by MUNI, BART, Caltrain, Golden Gate Transit buses and ferries, by bike and on foot. Supporting the Bike Kitchen is a natural extension of our desire to create a sustainable workplace and work life for everyone Carbon Five.

Compass, the 960 CSS framework, and Semantic Markup

Published by Aaron Brown on March 2, 2009 in CSS and HTML. 8 Comments Tags: , , , .

Finding your way to meaningful grid layouts using the Compass framework

My problem: Grid layouts – crazy, sexy, cool. Presentation classes in my semantic markup – neither sexy nor cool, and arguably crazy.

These days I can’t help but notice a burgeoning awareness regarding seasoned typographical principles and practices and lively discussions around the best way to bring these ideas and procedures to bear in the realm of web design. One area of these discussions that dovetails with my own interests is the subject of grid layouts. Grid systems are the architectonic foundation of a well structured and holistically interrelated design. They originated during the reign of the International Typographic Style, a primarily Swiss graphic arts movement which occurred after World War II. Grid layouts were cultivated and matured in the hands of such legendary designers as Emil Ruder and Josef Müller-Brockmann, acknowledged masters of simultaneously presenting information in a functional and stylistic manner. As web designers, I feel we should constantly strive for these same goals – the presentation of information in a readily understandable way, yet also striving for an elegance in our presentation. Grids can help us accomplish this goal.

Over the past few years much headway has been made in cultivating an online consciousness of Grid Systems. Khoi Vinh and Cameron Moll have shown us the benefits of using grid systems for web layouts, and Antonio Carusone from AisleOne has recently pieced together the awesome grid oriented hub, The Grid System. Further, a number of CSS based grid frameworks have been popping up on the scene. Those that have much traction in the blogosphere–Blueprint, YUI Grids, 960 grid system–are only the tip of the iceberg.

I’ve been interested in experimenting with one of these frameworks for a while, but I have a single nagging concern with the way they are structured. All of the frameworks I have looked at use CSS class definitions which possess names that reek of presentational concerns. For example, Blueprint requires class names like “span-7 last” or “span-8″; 960 favors the equally presentational “grid_1 prefix_1″ or “grid_7 alpha.” I just can’t get on board with this approach. I’m a firm adherent to notions of lean, minimal, and semantically vaible (X)HTML markup. The web development community has made great strides in separating out presentational concerns from the meaning inherent in well-crafted (X)HTML, divorcing the two orthogonal axes of style and semantics. And while I am a firm believer in the power of the grid to unify these two axes, as has been so well exhibited in the world of print, I cannot support said unification if it comes at the cost of reintroducing presentational markers into our markup – even something as ostensibly innocuous as a ‘mere’ presentational class.

So, where does that leave us? Is it possible to get the best of both worlds? Can we simultaneously develop semantic markup while leveraging those tried and true grid layout principles common enough to be packaged into a framework?

A potential solution to my problem: Compass – crazy? sexy? cool? To be determined…

Much to my pleasure, I am alone in neither my conviction nor my desire. Enter Compass, a ruby based application which provides Sass based APIs to many of the most prominent CSS frameworks, including those concerned with providing grid layouts. Compass sits on top of Sass, a domain specific language (DSL) for programmatically crafting CSS. The power of Sass derives from the fact that it is a real programming language, replete with all the benefits of such a thing: pragmatic tools such variable declarations, control structures, and method invocations, as well as more theoretical, but no less useful, concepts like abstraction, DRY-ness, encapsulation, modularity, and code re-use. I’ll admit, I’m new to Sass, having used it only superficially on a small work project. I have barely scratched the surface of its capabilities. And while some feel its application fails when applied to large scale projects, I can’t help but favor the programmatic benefits Sass brings to the table given my software engineering background.

Armed with Sass, developers can effectively write small libraries of code which will ultimately be translated into CSS. And Compass provides them with a mechanism for collecting these Sass libraries together and incorporating multiple APIs to into their own projects.

So, how does Compass help preserve semantic markup?

One of Sass’s most compelling features is known as a ‘mixin’. A mixin is a small module of Sass code, defined but once, that can be included into a Sass file and then referenced throughout. You can see where this is going. Imagine that in your application’s Sass file, you can gain access to, for example, 960’s grid layout API. You can ‘mixin’ these snippets of Sass code directly into your own semantic class definitions forgoing the need to use 960’s presentational class names anywhere in your (X)HTML. In short, Compass grants you the power to marry a tightly structured grid-layout with the beauty of lean, semantic markup. Pretty nifty, no?

So I decided to put all this to the test. I needed to learn more Sass, I wanted to play with the 960 grid system, and I wanted to vet Compass’s claim that it can help you eat a grid-layout cake iced with sugary semantic goodness. Follow along if you will…

Sussin’ the Solution: My first Compass-960 project

Installing Compass and the 960 plug-in

Since I already had Ruby and RubyGems installed, I was ready to start straight away with the installation of Compass.

First, I installed the bleeding edge of Haml, which includes Sass:

$ git clone git://github.com/nex3/haml.git
$ cd haml
$ rake install

I verified my Sass installation:

$ sass -v
Haml 2.1.0

Good to go. Next, I installed Compass and the 960 plug-in:

$ gem install chriseppstein-compass
$ gem install chriseppstein-compass-960-plugin

Creating a Compass-960 website project

Time to create a template Compass-960 project:

$ compass -r ninesixty -f 960 the_obscurantist

Now I had my template project, which comprised:

$ find the_obscurantist/
the_obscurantist/config.rb
the_obscurantist/src
the_obscurantist/src/grid.sass
the_obscurantist/src/text.sass
the_obscurantist/stylesheets
the_obscurantist/stylesheets/grid.css
the_obscurantist/stylesheets/text.css

Out of the box, the 960 plug-in produced two Sass files, grid.sass and text.sass. These two files mirrored the CSS files that come with the 960 framework, 960.css and text.css respectively. Whe I inspected the *.sass files, I noticed they already contained code to get me up and running with a basic 960 grid layout.

At this point I took some time to finagle things into a state commensurate with my overall goal – the elimination of 960’s presentational class names. First, I wasn’t interested in 960’s typography, so I ditched text.sass and text.css. Second, I also ditched grid.sass and grid.css, because those files provide access to styles designated with presentational class names, for example: ‘.container_12′, ‘.grid_4′, etc. Next, as learning exercise, I converted my variation on Eric Meyer’s CSS reset to Sass. Finally, I set up an application.sass file, being sure to include the 960 API and Compass’s clearfix module.

@import compass/utilities/general/clearfix.sass
@import 960/grid.sass

Ok, cool. I had some Sass files, but where were my CSS files? Simply enough, I had to run Compass to generate them.

$ compass
   exists stylesheets
  compile src/application.sass
identical stylesheets/application.css
  compile src/reset.sass
identical stylesheets/reset.css

Manually regenerating your CSS files everytime you make a change is burdensome. Compass can be run as a process that detects changes to your source files and automatically regenerates your css. I’ve found that leaving this process running in its own shell is useful so I can keep an eye on the Sass log for parsing errors.

So I ran compass as a daemon to forgo manual re-generation:

$ compass --watch

Great. Setting up a basic Compass project went off with out a hitch. I added in the remaining requisite files — an index page and the jQuery javascript library — and was ready to… Oh wait, what am I building?!

Using 960’s handy design resources to brainstorm ‘The Obscurantist’ daily newspaper

Because my whole endeavor was motivated by an intuitive yearning for transparent and easily interpretable semantic information, I decided to tip a hat to my favorite muse, Bittersweet Irony, and design a newspaper that had but one purpose – proffering the opaque and the impenetrable. Enter, The Obscurantist! As newspapers traditionally adhere to very strict grid layouts, the Obscurantist would allow me to learn the basics of the 960 framework.

In my view, some of the most useful resources provided by the 960 framework are the sketchsheets and grid templates. The sketchsheets were great for quickly thumbnailing rough ideas.

Here’s an example of a sketchsheet, marred only by my attempt at artistic expression:

Example usage of the 960 frameworks 16-grid sketchsheet

Example usage of the 960 framework

16 columns was overkill, so I decided to fire up Illustrator and utilize 960’s Illustrator 12-column grid template as a background layer to help me lay out my page design. (960 comes with a range of templates catering to the most prominent graphics programs.)

Here’s the final design:

The Obscurantist Illustrator layout using a 960 template file as background layer

The Obscurantist Illustrator layout using a 960 template file as background layer

Mark It Up

The next step was converting my design to semantic and valid XHTML. This post is already long enough, so I won’t bore you with the details. Suffice it to say, I tried my best not to let presentational concerns influence my markup. By keeping things as semantic as possible, I set the stage for seeing how well Compass would facilitate leveraging 960’s layout structure in spite of the framework’s presentational class names. Feel free to pop open firebug and check out the The Obscurantist’s markup for yourself.

Stylin’ with Sass, 960 degrees o’ heat, straight sexified son!

The next step was to implement my 12-column grid layout in application.sass. As I had already designed The Obscurantist in Illustrator using the 960 grid template as a backdrop, coding up the grid was very straight forward. It turns out I can count to twelve, so I was in good shape. I’ve included the relevant aspects of application.sass below. Read it over, and below I’ll explain Compass’s 960 API in more detail.

@import compass/utilities/general/clearfix.sass
@import 960/grid.sass
 
/* ...omitted for brevity... */
 
#container
  +grid-container
  +clearfix
 
  .title
    +grid(12,12)
 
  .publication-info
    +grid(12,12)
    .volume
      +grid(2,12)
      +alpha
    .date
      +grid(8,12)
    .number
      +grid(2,12)
      +omega
 
   #article
    +grid(12,12)
    .body
      +grid(7,12)
      +alpha
    .captioned-photo
      +grid(5,12)
      +omega
 
  #sidebar
    +grid(12,12)
    img
      +grid(5,12)
      +alpha
    .body
      +grid(7,12)
      +omega
 
  #tagline
    +grid(12,12)
  • ‘+grid-container’ establishes the overall 960px wide centered layout
  • ‘+grid(m, n)’ assigns an element a width based on the number of columns(m) it should take up with respect to a number of total colums(n)

Keen readers will notice that while the 960 grid system supports only 12 and 16 column layouts, +grid(m,n) is a method call which supports any number of columns. That’s right, Compass provides a completely customizable 960 pixel wide layout. The various column widths are calculated when Sass generates your CSS. (More on this below.)

So what about this ominous sounding “Alpha” and “Omega” business? As it happens, the 960 framework defines a gutter of 20px, each neighboring element contributing a 10 pixel margin to the overall gutter. Therefore, there will be a 10 pixel margin on the left and right hand sides of the overall grid container, constituted by the left side of the first element in a row and the right side of the last element in a row. (Check out The Obscurantist in Firebug for a better understanding.)

But, what happens if you are nesting grid elements? In that case you don’t want the child to re-contribute 10 pixels of outside margin, as the parent element already took care of this. What do you do? Simply demarcate the left most nested element as the ‘Alpha’ and the right most nested element as the ‘Omega’. Doing so will remove the outside margins and your grid layout will remain locked in place.

One additional note, the container element has had a clearfix applied to it, so that it will expand to
contain its floated child elements. This allowed me to attach 960’s 12-column grid image as a background to ensure my layout exactly matched my mockup.

The end has come: Sexiness – attained. Coolness – attained. Craziness – Why not?

The end result – The Obscurantist. You can toggle the 12-column grid background using the button in the upper right-hand corner.

I’m sold. Compass successfully allowed to me attain my goal: overall clean, minimal, and semantic markup and a rigid adherence to an underlying grid-system.

Finally, the example site is up on github, feel free to peruse it if you need a more comprehensive view of the working parts.

$ git clone git://github.com/aaronsbrown/obscurantist.git

Final Thoughts and Takeaways

  • My background is in server-side software development and therefore the client-side space and its attendant technologies are relatively new to me. Before I experimented with Sass, I took it for granted that styling presentation via CSS was categorically a different process than developing software. But Sass directly counters my assumption. And even though I no longer directly write CSS when coding with Sass, its DSL makes me feel right at home when describing my presentational styles. Most importantly, Sass gives me the ability to bring my software engineering practices to bear in the presentational realm. I can’t help but think this is a big deal.

    However, I will say getting comfortable with “programmatic” CSS took a bit of mental re-orientation. I was used to having all my style definitions right in front of me, explicit and clear. Yet Sass, especially when coupled with Compass, introduces to the CSS space welcomed notions of abtraction, like modularity and encapsulation. As such, things are no longer directly in front of me. Rather, I have to approach coding CSS with the mindset of using libraries. So i have to fire up the docs (in this case the 960 plug-in Sass code), see what resources the library provides, and then determine the best use of those resources. Again, I go through this process daily when writing application code, but it felt a little awkward when first incorporating this practice in the CSS space. But once I began approaching coding my presentation layer like any other programming task, things immediately fell into place. Also, because the end product of the Sass work cycle is CSS, I had ready access to those files if I wanted want to see what was being sent to the client. And since I use Firebug as my main debugging tool, my approach to debugging the presentation layer didn’t have to change at all. 

  • I think that for small personal and professional projects Sass and Compass will help streamline CSS development. The ability to modularize and re-use code is a big win in terms of best practices and efficiency. It can also help maintain consistency throughout the code base. I think the tool would even be useful in large-scale organizations where the developers share similar values and engineering practices, and whom are disciplined enough to learn and use the Sass/Compass libraries.

    I’m perhaps a bit more skeptical about the promise of Compass to distribute reusable CSS plug-ins throughout larger engineering ecosystems. While there are surely commonplace CSS problems, I think the idiosyncratic nature of website design will at some point outweigh the ability for large scale CSS reuse. But, I do hope I am wrong on this point, as I feel Compass’s aims and values are admirable. Time will tell.

  • There is one big concern I have with respect to using Compass to maintain semantics, and it concerns optimization. The Sass ‘mixin’ model basically inlines style attributes (from, for example, 960) into your own custom CSS. The (potential) downside of this is lots of duplicated CSS rules in Sass’s generated end product. How might this model impact the file size of my custom CSS? And how to weigh this increase in file size against the benefits Sass and Compass bring to the development side of things? Are we sacrificing consumer performance for producer best practices? I don’t have an answer to this question. If anyone out there can speak to this issue, I’d love to hear your thoughts.

    If I have time, I would like to implement The Obscurantist with only the 960 framework, sans Compass, and compare the resulting CSS. I’ll just have to stomach presentation class names in my markup for the sake of enlightenment.

  • Given the programmatic nature of Sass, the Compass port of the 960 framework is extremely customizable. In effect,you get an API to generate a grid of N columns, each separated by a configurable gutter, that all together span 960 pixels. For example, let’s say you want to create a layout that is 960 px wide and comprises 5 columns separated by 10 pixel gutters. It’s pretty easy: 
    @import 960/grid.sass
 
!ninesixty_gutter_width = 10px
 
#container
  +grid-container
  #main-content
    +grid(4,5)
  #nav
    +grid(1,5)

    I encourage you to dig into the 960 plug-in’s Sass files to see what other things you can tweak.

  • More generally, there seems to be a growing number of Compass modules available. Some modules come installed with Compass, while others are available as plug-ins. Therefore, you can pick and choose from various CSS frameworks as the need arises. Say you love 960’s approach to grid layouts but you prefer Blueprint’s typographic standards. Well, Compass allows you to selectively incorporate mixins from both frameworks. And since you don’t have to rely on the frameworks’ class definitions you remain in full control of your semantics.
  • And finally, a few words about the 960 CSS framework. I’ll be honest, when all was said and done, I thought – “All this for some width and margin definitions? I could have come up with that on my own with not much effort. It all seems pretty simple.” But part of me thinks such a reaction reflects, perhaps ironically, rather well on a framework. 960 does one thing-it helps you execute a grid layout rapidly, easily, and with little preparation. It doesn’t get in your way and simply optimizes and enhances your work-flow. And while it makes grid layouts seem intuitive and transparent, I’m quite sure there are subtleties hidden away that I’m not taking into account with my cursory ascription of, “That seems pretty simple.” So I’m perfectly happy leveraging the hard work of people who have spent more time focusing on grid layouts and spending my time concentrating on other aspects of my project.

    Also, and perhaps most importantly for me, the 960 framework sports the following tagline: “Sketch, Design, Code.” As I hope this article has demonstrated, I was able to utilize 960’s resources starting with the brainstorming phase (via sketchseets), during the design phase (via grid templates), and finally throughout the implementation phase (via the grid template background images and the Compass plug-in). In short, 960 provides helpful resources that can, and I would argue should, be used from project inception to project end.

In summary, if you want to leverage CSS frameworks while maintaining the semantic purity of your markup, take a moment to check out Compass. I think you’ll find it opens up a great new space of possibility.

Resources: