Q&A with Lead Front-End Developer, Trent Stromkins

ImageX’s front-end development lead, Trent Stromkins, brings a unique background to his role. As a former designer, he uses his love for good design to develop with aesthetics and user experience in mind by marrying form and function. We spoke with Trent to discuss his experience and his thoughts on where design and development intersect.

I first started in development in 1997 working on static HTML pages, then moving on to PHP and database based sites. At the same time, I was working on a career path in architecture but realized that it wasn’t for me so I used those skills to get into design. I worked professionally in packaging design, all the while building my skills as a web developer on the side. I was getting tired of recreating the wheel on every project, instead of using components that could be efficiently repurposed, which lead me to join the Drupal community in 2007 just after Drupal 6 was released. In 2008 when the recession hit I was “economized” from my design job. This gave me the opportunity to change careers.

I merged those two experiences to fill what I thought was a weak spot in the Drupal community -- that you could often tell when a site was built on Drupal. It was there that I decided that front-end development was going to be my focus. Real-world web development situations, for the most part, are not easily defined as front or back-end work; we jump between both. I saw this as somewhere that I could add value, being that I had worked on many custom hand-built solutions along with graphic design in my past. 

In packaging design, you can design in Illustrator to precise specifications. But in the actual execution, there are variances -- press gain, skidding on the press, shape of the container, etc. that aren’t exact -- so you learn to adjust your designs to match the output. 

Similarly, for the web, your designs should adjust for how actual content will flow which means you can’t always be pixel perfect. You have to understand the output and make adjustments based on what’s realistic. You need an understanding of the CMS’ output, limitations that may be imposed by browsers, screen sizes, etc.

As a designer, I’m very familiar with design tools so I can speak the same language with other designers. I understand that tools have quirks -- like how fonts render in design files versus on the web, for example. I’m also able to fill any visual gaps in cases where there is no design for a piece, and being a designer, I can make those decisions informed by both disciplines. 

It’s always best to work with the designer and the client to help them understand where things can and can’t be exactly accurate. An example is colour space in Photoshop versus browsers. 

When you’re looking at the design, everything looks controlled and ideal. But when you’re building it responsively, by definition it adjusts. Designers sometimes tend to be too uniform in their designs -- content isn’t always the same, so it will appear and render differently than in the designs. We can’t make all things on the web exactly accurate to the file. The flip side is that not all developers can notice the details in things like line spacing, white space, or visual flow. 

A lot of developers won’t push back on designers because they don’t speak the language, even when the designs aren’t built within the best practices for management, or within the limitations of the CMS.

The thing that’s important is getting the design team to communicate with lead developer ahead of time, especially ahead of the client. Have someone from every discipline at the table early on -- don’t work in silos, as it’s always best to collaborate. To be working best, teams should iterate through each discipline. This also helps keep teams from chewing through a project’s budget by the time it moves down the chain to development or QA. Work with your team and clients to help them understand best practices on the web. Our role should always include education. 

Narrow down the elements of the page, almost like a style guide; show the variations of the elements; and build them as components that can be reused elsewhere on the site (similar to application development) following a universal standard. Also, build tools that enable the layouts and components to be repurposable, and deployed more efficiently throughout the site.
 

Practice componentized design. Design almost like a style guide where you create one design for the overall page and the rest show the variances of any different states. Make sure the components are cohesive and modular and then they become like template options. Working into this trend saves time for both design and development and ideally gives a realistic approach on how it gets assembled.

It also helps when the designer can show examples of how they envision an interaction effect to work on the web, so always give references wherever possible. Using them, developers can determine the specific execution as well as if it’s within budget. 
 

React.js has brought into the light some interesting concepts, such as that of using small components, one direction for data flow, and other techniques that make sites and web and mobile apps more modular. When you build websites in a way that allows the growth, evolution, and development of a site to take a componentized form, updating a component doesn’t break the site, it enhances it.

The concept of the web being an application interface and having your site interact like an application -- fast, responsive, and even offline has really got my imagination going. People don’t need to install applications any more, the web as an application is becoming more acceptable (Google docs, Slack, etc.). You can design and build what used to have to be a “native” application, but now have it cross-platform, for the browser, or a web interfacing native shell like Electron. 

Time will tell, but I see great things for the future of the web!