Dev Chat: Joe Cardella and Adam Kempler

Dev Chat 1: Adam Kempler and Joe Cardella

Developing a Drupal component-based solution for Missouri Department of Transportation

For our very first staff Dev Chat, we spoke with developers Joe Cardella and Adam Kempler about collaborating on the Missouri Department of Transportation (MODOT) site redesign.

This project was an extensive overhaul of an important communication tool for transportation in the state of Missouri. Highlights include a customized Drupal component-based approach to organizing content.

What stands out about being a developer on this project?

Joe: Culturally, I’ve found that the company is committed to high performance through collaboration. Developers are encouraged to explore new technologies and share skills and insight to a degree that naturally spurs both professional growth and product innovation. This means the client gets a custom product that closely suits their needs, and the staff is able to learn from the process.

Adam: We have a lot of opportunity to innovate to fit the needs of a specific project. In the case of MODOT we executed an in-depth discovery to identify requirements and make recommendations in terms of features functionality and content. A good discovery process provides a product of its own. That determines the roadmap for what needs to be built.

As part of discovery we did an audit of all website content using Scry, a custom-built tool for cataloging content. This helped to determine the content patterns and components. These included things like headings (h1s), galleries, summaries, slide shows, groups of links, accordions, and other reusable content elements. Once we identified all of the existing content, we determined what other kinds of content their audience was seeking. This might be a social media block that contains Twitter, Instagram, or Flickr feeds, or an easy-to-update news section.

Many government sites, like MODOT, have been around 10 years and have accumulated content over those years from a variety of sources, so there can be a lack of consistency. You might have multiple things that look wildly different but actually serve the same purpose, meaning that they are actually the same component. So part of this effort was to create guidelines enforcing site consistency.

How did the component process evolve?

Joe: We’ve been focused on evolving our usual theming process to make it more efficient and robust. The component-based approach offers big opportunities for efficiency and consistency during the development phase of the project, and that same efficiency and consistency pays off for site administrators once the site is launched.

Our design team created the look and feel of the site by establishing a few simple visual patterns. These are then re-used and composed together to make user interface components dedicated to showing off certain kinds of content – an image gallery, or a list of links, for example. We developers were able to translate that design into code that could be re-used and combined in similar ways. As we progressed through the project, we began to build new components by combining already developed and tested code, rather than creating new code.

Adam: By creating a backend architecture of reusable components for content editors to create, we were able to implement a pattern library and supporting technology. This allows the developers and the client to very quickly and efficiently add components across the different pages.

This is an approach that has been a best practice for a many years. The challenge was how to do it in the Drupal space. At first, the traditional approach to organizing information in Drupal and this component approach seemed technically at odds. So we sought a way that was both easy to apply consistently and easy to get other developers on board.

With each project we adopt more aspects of this strategy. MODOT is the best example yet of where it’s all come together. The focus on discovery really helped make this happen. Getting a clear picture of the content arms us with the info we need to figure out what we need to display. And it allows us to tailor an approach that works for the objectives and needs of the client.

Why are components beneficial?

Joe: On the development side, the value of components lies in the ability to significantly lower the effort required to create new user interface elements over the course of the project. It saves time in development, testing, and bug fixes. It makes ongoing maintenance easier and less error-prone, and it allows for faster ramp-up time when we need to bring new members onto the development team.

Adam: Another nice thing about the component approach is that it allows for content reuse. The common page-based approach inhibits that in a lot of ways. With components you can redisplay the images or statistics from one story in many locations throughout the site without duplication of that resource. Content is doubled up in different ways and repurposed to create other kinds of content. As well, end users can search for and access content in a variety of ways.

Furthermore, we’ve customized Drupal so the technology should be invisible to the client’s site administrators. They shouldn’t have to know about Drupal or how to administer Drupal. People who create content on a day-to-day basis should easily be able to do so on the admin site. The technology shouldn’t get in their way.

How will you build on this?

Joe: We will build on this approach by continuing to streamline and improve the end-user authoring experience. There’s always room to refine and simplify the components so they become as easy to use as possible. We also want to continue to improve how the bits of component code work together. This assures that the design stays bullet proof and doesn’t wander over time as new developers and content authors engage with the site.

Adam: It’s an iterative, constant evolution toward simplicity. At the end of a project we identify the pros and cons of our technical, design, and UX approach. These findings are documented and shared to lay a foundation for continual refinement and improvement with each project. This, in turn, benefits future clients.

What’s next?

Joe: Going forward, I’d like to see us expand the opportunities for mentorship within the development team. Due to our exceptionally collaborative culture, our environment can be beneficial for developers who are still in the early stages of their careers and possess a high aptitude for learning and a strong drive toward professional development.

Adam: As projects allow, we’re starting to build more intelligence into websites. These behavior-oriented recommendation engines and chatbots connect users with content. When sites have a huge amount of content to search through, such tools help users quickly find relevant info beyond the navigation menu. We see many large sites moving away from static information delivery to intelligent delivery catered to the particular user.

Stay tuned for more on intelligent delivery in an upcoming post on smart content connectors.

Team bios

Other team members were project manager Sarah Crossman, designers Peter Clark and Christopher Prinn, UX specialist Amy Mauriello, QA specialist Todd Merry, and developer Joseph Descalzota. Meet everyone on the team from Portland Webworks, GovWebworks’ parent company.

Join our team

We are always seeking developers to build innovative solutions for our growing client base. We have a great benefits package and annual profit share averaging 16 percent of base salary. Located in Portland, Maine’s charming Old Port, employees enjoy in-house yoga, Friday happy hour, and other great perks.

Currently, we have the following developer openings:

To learn more about us, we hope you will check out the Portland Webworks team, and our Facebook and LinkedIn pages. You also might like our MailChimp-style report on company stats and figures, the 2017-by-the-Numbers report.

Feel free to contact us with any questions!

Learn more

Related posts

Was this post helpful?