Searching For the Perfect Web Development Workflow
January 25, 2013Tweet
I have this great puzzle in front of me: how do I create an efficient web development workflow? A good workflow allows for a team, such as a designer and developer pair, to work in a way that each of their steps complement each other. It segments steps in a way to optimize how much time can be spent on them while increasing the overall speed of the project. For a web developer, a good workflow allows for clean code and incorperates tools that maintain organization throughout the process.
What I’ve found is that this search is a constant process of evaluating, implementing, failing, and reevaluating.
What follows is a recap of my journey so far as the Lead Developer at Suits & Sandals, LLC.; from the begining to what I hold currently as truths. This is as much for me so that I may keep a copy of where I was in my journey as it is for those who are developing their own workflows.
So let me begin.
Prior to about a year ago I did not think about workflow and my team’s output reflected that. We moved in a disorganized fasion, stumbling over each other without a plan for the completion of the project. This was represented itself in sloppy code that broke across different browsers and that was difficult to update once “finished.” It led to huge delays in development time and never ending revisions and corrections. Most importantly it wasn’t fun anymore. We were all becoming frustrated and that also showed through.
Finally there was a project that forced me over the edge. I had to admit that there was something wrong. Despite our knowledge and our longing for excellence we were still putting out crap.
That’s about when I found Nicole Sulivan, or more specifically her ideas about Object Oriented CSS (OCSS). “As with any object-based coding method, the purpose of OOCSS is to encourage code reuse and, ultimately, faster and more efficient stylesheets that are easier to add to and maintain” (SOURCE).
What my team had been doing was making a new class for every single element of our site. While there was reuse of classes there were many more instances where there were several classes that looked very a like except for a few attributes. Despite the use of a responsive grid system, most of the variations in classes were due to margins and padding. Our code was bulky and unorganized. This decreased the ease of which it could be updated and made bugs quite frequent; especial when switching between browsers.
This was exasperated by the fact that we would loose track of what each other was doing and would create duplicate classes.
To me OOCSS can be broken into two key ideas
First: DRY. Code must be reusable. A class should be distilled down to basic aspects in order to be used over and over again.
My response to this was the make classes that were single attributes (or attributes that were often used together). Each background, font (color and size separate), border, etc. was its one class.
Second: Skin and layout MUST be SEPERATE. Skin is any stylistic element (color, font-family, border, shadows). Layout is any positioning element. This very similar to the first but is central to understanding how this aids development.
My response to this is again similar to the first. I continued to use a grid and created special padding and margin classes that followed me from project to project. Each class represented a different size of spacing and a different direction.
OOCSS not only decreased the bulk of our stylesheets but improved are workflow as a team. The style classes were now created at the beginning of each project and “styling” consisted of adding classes to elements as per my direction. It was now much easier to collaborate on coding.
From the first project we implemented this process our development time decreased, our style sheets became less bulky, updating styles became quicker, and are likelihood of encountering bugs decreased.
I created my first “framework”, a blueprint of classes and elements, that enforced this new philosophy and gave us a head start in our projects. The creation of “frameworks” that reflect my current approach to web development has become a staple of my practice and allows me to get into my rhythm a lot quicker.
It took us a project or two to fully master this process, but by the time we had it was already beginning to show its weaknesses. There also began to arise issues of miscommunication between the design and development teams.
Breakdown in The Process
When we got our first large scale project since the change in approach a lot of our flaws became quickly apparent. Due to several early issues in the management of the project the completion of a finished design mockup had been delayed. In order to keep on time I began development of a design proposal we were certain would be accepted. However, while we did receive initial approval, several changes were made while development was in progress. Without proper communication between design and development, the code gradually became disorganized due to large changes to the layout and skin of the design.
Further, these changes highlighted a major flaw in how we had gone about OOCSS. While breaking our classes done into tiny pieces had decreased bulk within the stylesheets, it had increased bulk within the HTML. We found ourselves having to go through page after page replacing classes. All we had done was move our original problem of disorganized bulk from the CSS and into the HTML.
Analysing the Workflow
I first tackled the issue of the breakdown in communication between the design and development. I realized that if the breakdown had caused so much damage with our small team, the damage would only increase as we eventually grew.
I broke down the steps in both the design and development process and isolated key areas where the design and development overlapped; namely in the creation of the skin and layout styles. I then created a process diagram that would put roadblocks in place to force cooperation without hampering time efficiency.
The design team would create the information architecture and layout while the development team prepared non-design oriented code (php, javascript, etc.). The design team would then hand over the layout and begin work on style tiles and a rough. Once the client approved the style then the developers and designers work together on creating the css; more on this later. After that a first draft of the site is made, client signs off, and then the final draft is created.
Local Development and SASS
A crucial change came in with the creation of the css. For a while we had been developing on a dedicated server. However, this “live” coding prevents a developer from using preprocessor meta-languages, like SASS, that’s “used to describe the style of a document cleanly with more power than flat CSS allows. Sass both provides a simpler, more elegant syntax for CSS and implements various features that are useful for creating manageable stylesheets.” SASS and other such meta-languages must be compiled locally using the command line or GUI interfaces like Codekit.
SASS specifically allows for variables (stored bit of simple data) and mixins (chunks of CSS attributes that can be added easily to the styles of elements, classes, etc.
We were able to translate the idea of “basic elements” of style, that had previously been stored in a large number of simple classes, in variables and mixins. When the designers and developers create the SASS, they first fill in variables and mixins based on a framework I developed (which incorporates Compass). They then use these building blocks to create larger, reusable classes. If a style needs to be changed it is done so by changing the value of a variable.
As a rule I suggest using some sort of version controll on all projects. Version control not only helps to keep track of changes but allows for a team to easily toss files back forth. Suits & Sandals uses .git and host our repositories on GitHub with a private bussiness account.
We have just begun to implement this new process. It is still a work in progress and forever shall be.
Please ask any questions or give any pieces of advice in the comments.
EDIT 1/25/13 — I highly suggest checking out this article by my business partner Miles Roxas about our lessons in client relations. A great companion piece to this article.
Bugs etc., CSS, Discussions, SASS, Web Design and Development, Web Tutorials, Workflow
