Responsive projects are a big undertaking. There are a lot of things to track. Storie, devices, requirements, wireframes, mocks, and bugs just to name a few. In a recent Responsive project, we worked with [Lenovo](lenovo.com/us/en/) and [Sparkbox](http://seesparkbox.com/) to create a responsive version of Lenovo’s existing e-commerce website. The project consisted of three teams. Sparkbox created the markup and styles for the static templates, appendTo wrote the JavaScript, and Lenovo’s internal team was responsible for integrating the templates into their CMS. Having this many people put a lot of talent on the project but it made coordination more of a challenge. Luckily we’re already remote at appendTo, so we’re used to managing teams who are in different places. Here’s a look into our workflow and processes as we coordinated between multiple teams.

## Tools
We were resonsible for delivering static templates with mock data. The project environment was set up to cater to that. For styles we used [Sass](http://sass-lang.com/) and [Compass](http://compass-style.org/) and for JavaScript we used jQuery and a [module pattern](http://addyosmani.com/resources/essentialjsdesignpatterns/book/#modulepatternjavascript) to call only the peices we needed for each page. One of the reasons the project went so well is that we utilized a task runner – specifically [Grunt](http://gruntjs.com/). This saved a time of time by doing stuff that had to happen each time we wanted to view a change. This would have taken several minutes if we had to do it manually but was cut down to seconds for each build. Here are some of the things Grunt did for us:

* Watch the Grunt file for changes
* Watch and compile Sass files using Compass
* [Livereload](http://livereload.com/)
* Assemble each template’s modules
* Insert data into each template page
* Build the Style Guide
* Run [jshint](http://www.jshint.com/about/) to validate JavaScript
* Run [Jasmine](http://jasmine.github.io/) tests on our JavaScript
* Concatenate JavaScript files

## Breaking it up
Instead of creating just by pages, we had a focus on modules. One person may work on the cart module while another would work on the product-specs module. During build all the modules are added to the Style Guide page. This way every module can be tested or viewd on a demo all at once. Modules were then cherry picked and placed an each template that as needed.

## Working together
Each Monday the development teams (JS and CSS), as well as Engagement Managers, would meet to discuss last weeks progress, tie up loose ends, and prepare for the demo. On Tuesdays, everyone met for the demo, to discuss upcoming tasks, and to review proposed designs and wireframes. These meetings were done using GoToMeeting or Skype.

Obviously having a team for JavaScript and a team for CSS doesn’t mean they won’t need to collaborate at times. For those times we used Skype to chat or scheduled meetings adhoc. We worked closely with Lenovo for a less encountered challenge. Their templates have to house several languages as Lenovo distributes all over the world. This required a fair amount of communication with their internal team as we tweaked the templates.

One position we have on every project at appendTo is Engagement Manager. Our Engagement Managers make sure everything is operating smoothly. They communicate with the client, facilitate meetings, and do their best to keep everyone happy and focused. Communication is key when working remotely with other companies and Engagement Managers make that happen.

## Bug tracking
Bugs are a part of any project. With Lenovo we used Github issues to track bugs. This allowed everyone working on the project as well as the client to submit and discuss bugs. Using git and Github’s hash system we were easily able to reference bug fixes in pull requests and mark them as resolved. This was a big help in tracking code directly with bugs.

## Code management
As mentioned before, we used Git and Github for version control. A developer would create a branch for the module or feature he or she was working on. Once a feature was complete and committed a pull request was made (Which is pretty standard). We had two people in charge of pull requests who acted as gatekeepers. One person from appendTo reviewed all JavaScript pull requests and one person form Sparkbox handled all style related pull requests.

Pull requests were merged into our development branch and after each demo all approved modules were merged into our Master branch and tagged with a release number.

## Testing and Deployment
Sparkbox set up a server that they kept in sync with the development branch. We used this for user testing, browser testing, and the client was able to access it for demos.

Deployment was handled by Lenovo’s team. They took the static build and integrated it into their CMS. Any problems along the way were filed as Github issues and resolved by the appropriate team. We worked onsite with the Lenovo team for a couple of weeks to help them grok our code and to give some hands-on mentoring to get them into a responsive mindset.

## Wrapping up
At the time of this writing the responsive templates are still in the process of being rolled out. Becaue they sell internationally Lenovo has several sites. The first site to feature the responsive codebase was [Lenovo’s Austrailia site](http://www.lenovo.com/au/en/). So check it out.

This was a fun an challenging project and best of all we have a happy client. We’ve recieved great feedback from them stating that it was a well-run project that globally achieved cohesion among their internal team members that they hadn’t had on previous projects. Thanks to Lenovo for the kind words and thanks to Sparkbox for helping us make it happen.