Pairing Tour Day 2 - Nick Meccia

Today I paired with design craftsman Nick Meccia. I was excited to pair with Nick because I only know the basics of design, but don’t know how designers do their thing on a day to day basis. I was also curious to see how designers interface with developers, and what collaboration is like between the two. Today proved to be an interesting day of pairing, mostly because we got to start from the beginning of a story and work it to near completion. This involved starting with a design, presenting the design to one of the team leads who signed off on the idea, and then implementing it by making changes in the back end to help make data necessary for Nick’s design available in the HTML view.

Our story involved redesigning a couple of forms that allowed a user to schedule a payment. Originally the user was presented with a form asking them to submit the date they would like to make a payment. Once that form was submitted, the user was presented with another form asking them how much they would like to pay. One of the things that immediately stood out about Nick’s approach to user interface design was his emphasis on eliminating anything unnecessary from the experience and highlighting the information that was most critical to the process.

From having a conversation that focused on the most fundamental and important parts of the user experience that was detached from the context of the application, we were able to see past what was already there and imagine a more efficient and intuitive experience for the user. This led Nick to decide that one form was easier for the user to grapple with, and that certain data not being presented should be included in the view. We also removed some data that was not necessary for the user. Reducing the noise the user had to experience helped the design emerge naturally.

After walking through the design and having a clear agenda, we set in on making changes to the back end of the code. This was a Rails application, so I felt pretty comfortable working in that environment. It was not easy though understanding how this one application fit into the larger picture of a suite of applications that all communicate and share data with each other. However, getting the initial layout of the new form design was straightforward.

Things got more interesting when I proposed to use ajax calls to retreive some calculated data, and dropping that data in dynamically in the view so the user could have immediate feedback. I was pleasantly surprised to see that the main javascript file in use for this particular part of the application was a coffeescript file. After adding in a new route to the controller, updating the routes file and hooking it all up with the ajax call, we were able to provide the user with immediate feedback.

The controller changes got a little more complex when we started converting the two separate form routes into one route. Because certain things were calculated in both, and certain exceptions were being caught in both routes, it was a little tricky combining the two routes into one without potentially breaking things down the pipe. To further complicate things, the tests for this particular controller only tested one of the routes, leaving one of the routes completely untested. Not knowing much about what the expectations were for each route and only having one day to work on this story with Nick, I had to reason that the best approach was one that would leave both operations as intact as possible and not alter the behavior. I felt pretty nervous working on code that wasn’t wrapped in tests, and was a good reminder of why tests are so important in guaranteeing a high level of code quality. Nonetheless, we were able to get the feature working at the very end of the day.

After the day of pairing with Nick, I returned to the Chicago 8th Light office to wrap up a story on an internal application for 8th Light with fellow apprentice Ryan Verner. We were having some trouble getting the last few tests to pass even though the feature was working. This was due to the setup of the test environment, and the way the controller was being stubbed. We then received a nugget of wisdom from craftsmen Brian Pratt who showed us it is possible to stub on a Rails controller object in the precise way we needed in order for our database query to lookup the correct user - an oversight on my part that could have saved quite a bit of time. With that new stub, we were finally able to save and load our test user to the database and confidently prove that the last step of our feature met the requirements.

Today was great because I got to experience design from a designer’s perspective, and the collaboration between designer and developer was an interesting experience I’d really enjoy doing again. Nick’s unique sense of humor and domain knowledge also greatly aided the day’s efforts. Working on the internal app this week has been a very enjoyable experience. It’s introduced me to a few new patterns I’ve not seen before. Most of all though, getting to pair with another apprentice and learn together has been helpful and rewarding.