Quick Thoughts from ConvergeRVA 2013

This past weekend, most of the FED team attended the first-ever ConvergeRVA conference down in Richmond, Virginia. In fact, our very own Dan Tello gave a fantastic presentation of his work on Run, PUMA, Run.

The team at Unmatched Style organize a number of Converge conferences every year. This was my first time attending a Converge, and the event didn't disappoint. While the conference was light on overarching themes, the diversity of topics presented easily made up for any thematic shortcomings.

Taking Risks

Both Dan and Bryce Bigger stressed the importance of taking risks in their presentations. For Dan, Run, PUMA, Run was an opportunity to try his hand at game development, something he (and Viget) had little experience in. For Bryce, his challenge was building a web-controlled, autonomous NERF blaster for the folks at MailChimp.

Neither Dan nor Bryce knew exactly how they would tackle their challenges, but they did so with enthusiasm and passion. Bryce offered two pieces of advice that resonated with me:

Make time for learning.

No one will take your career to the next level but you.

Taking risks isn't easy and you may not always succeed, but you will absolutely learn more along the way than if you'd avoided the risks altogether.

Don't Repeat Yourself

Staying DRY is one of the core principles of software development. Whether you're designing, developing, or user experience-ing, avoid repetition!

Dave DeSandro spoke to this principle while presenting Bower, a package manager for the web. Bower, as Dave explained, is an unopinionated solution to the problem of managing and maintaining all of the "stuff" that ends up in front-end development projects.

How many times have you hit up jQuery's website and downloaded yet another copy of the library into your project? Bower gives you an easy-to-use command line interface that quickly adds libraries like jQuery (and related dependencies) to your project.

Bower allows you to create more modularized pieces of code—whether that be one-off methods or full-featured plugins and libraries—and easily include those modules into any number of projects. Dave explained how he was able to abstract shared bits of functionality from Masonry and Isotope and in turn include the shared functionality back into those projects.

Dave's approach dovetails nicely with Brad Frost's Atomic Design concept, which was referenced by several speakers. The goal? Create discrete, reusable, systematic pieces of code/interface/functionality.

The Responsive Web Design Process

Responsive web design is about a whole lot more than layout.

Ben Callahan kicked off ConvergeRVA with a barnburner of a presentation, detailing how the team at Sparbox approaches responsive web design projects.

Ben outlined a three-phase approach to problem-solving:

1. Establish the Aesthetic
2. Solve the Problem
3. Refine the Solution

Establishing the Aesthetic

This phase, Ben points out, requires that we use tools we are comfortable with. These tools may not necessarily be Photoshop. Designers may use Pinterest boards to convey moods and feelings, style tiles to establish a visual language, and "style prototypes" (browser-based style tiles, essentially) to quickly engage clients in conversations.

Ben encouraged the use of style prototypes as a way to quickly bring up with clients conversations about browser differences and levels of support. Basically: get work into the browser as early as reasonably possible.

Solving the Problem

The second phase of the responsive design process centers around fluency. In this phase, design tools such as Photoshop, pencil and paper, or Adobe Edge Reflow are used to solve a project's unique problem. At Viget, Todd experimented with using Edge Reflow to quickly demonstrate to clients how various UIs might behave responsively.

Refining the Solution

In this final stage, static design tools (Photoshop, etc.) should not be used. The purpose of this phase is to iterate and refine the solution to the problem solved in the previous step.

Efficiency is key when you're refining a design solution.

This phase largely takes place in the browser and works best when the various roles in a project (designer, developer, UXer, etc.) can work closely together. As Ben pointed out, "you don't want to do the long tail of refining more than once."

We're thankfully past the point of convincing ourselves (and clients) of the importance of building responsive web products. The challenges now are in adapting our processes to meet the challenges and needs of the next phase of web design. Every agency is approaching the process shift in different ways, so I'm grateful to Ben for taking time to share Sparkbox's process.

In Conclusion…

I thoroughly enjoyed ConvergeRVA! A huge "Thank you!" to the organizers and the speakers for their hard work. It was a pleasure to attend and I encourage everyone to keep an eye out for an upcoming Converge conference.