Greg Gant
Front End Architect, UX Engineer

The Home Depot

Client: Home Depot

Website: corporate.homedepot.com

Position: Lead Front End Developer

Tech stack: Drupal, FaceBook / Instagram / Twitter feeds, Grunt, YouTube/Vimeo/Britecove support, Sass, JQuery.

Dev Time: 3.5 months

Overview:

Few businesses have the resources of The Home Depot. They are (#33 on the Fortune 500) and as of writing this employ 371,000 people across 2,274 store fronts and multiple offices. In a word, The Home Depot is massive.

Role:

Emerge Interactive partnered with The Home Depot's corporate team, which involved trips out to their Atlanta corporate office, where Emerge's Creative Team was able to flush out and finalize our designs. Home Depot looked to depart from the minimalist trend, to capture The Home Depot's Built From Scratch look and feel.

Pictured: Version 1.0

Unique Challenges:

Under The Home Depot's brand, they have several sub-properties, chiefly its "Team Depot" (outreach) and "Built From Scratch" (media). One of the unique concerns was how to move all the concurrent media channels into one seamless space; aggregating its social media streams (FaceBook, Twitter, Instagram, YouTube, Vimeo), media outreach and charitable causes. This included moving its previous website's content to the new website.

With an entity as large as The Home Depot, accessibility was chief concern. Our accessibility testing included matching to the A11y standards for contrast, screen readers, mouse-less navigation, javascript-less fallbacks and legacy browser support (IE9, iOS7). The long tail support meant eschewing some tools like Flexbox to ensure maximum compatibility. The client also had content previously developed for their old web property such as Hype 2 animations, not all of which were originally responsive which required tweaking to fit into the new responsive website.

See the Pen Tabindex return fix embed by Greg Gant (@fuzzywalrus) on CodePen.

Pictured (above):Example of a tab-index return fix to deal with the complexity of the slide shows and limitations of our CMS developed for home depot

As a personal objective, I set a hard limit of 675k of non-CMS assets as the site is incredibly image intensive, this included any image/js/css/fonts served as part of the template. It's easier said than done in especially considering high density imagery and the world of Drupal which packs quite a bit of its own necessary resources. I was able to obtain this through a barrage of front end patterns, such as minifying js and css assets and creating my own "Bootstrap-Lite", cutting out roughly 85% of the bootstrap code to avoid redundancy. Also added to the mix was a larger break point for larger screens. The end compiled CSS ends up weighing at an astonishing 31k when served through GZ compression and the entirety of the JS from the template (non-CMS) is 17.5k (excluding jQuery). The biggest gains to be had were on the template imagery side.

See the Pen Classic Accordion embed by Greg Gant (@fuzzywalrus) on CodePen.

Pictured (above: It's often easier to roll-your-own with common simple UI elements like accordions to ensure lightweight code and simplcity. This simple accordion menu takes only 10 lines of javascript prior to minification, which comes to 305 bytes minified.

Editing the images meant revisiting my digital arts degree, creating repeating texture maps from our PSDs, and running them through ImageAlpha, and experimenting. I was able to shave off precious bytes without sacrificing the visual integrity of the original design. In the end, I was able to shave hundreds of precious kilobytes off individual textures.

Pictured (above): 1500px x 300px (2x version) texture was for the header, 2x.

Some of the more inventive solutions came from the mother of all inventions, necessity. The Home Depot wanted to leverage modals. Not just modals for images but modals that contained slide shows, videos and downloadable images. The content contained in these modals also needed to be CMS managed. A single page could trigger multiple modals. I need to stress: they really liked modals. (Some battles just cannot be won.)

As a mulled this problem over, I hated the idea of polluting the DOM with so many modals and burdening the browser with senseless iframes that may not ever be seen. I decided my path would be to leverage a single global modal that would be populated only at the point of an interaction. This presented another problem, I needed to be able to trigger often sets of images from a single line thus I arrived at a surprisingly elegant solution: make the CMS spit out the code in JSON into data-attributes, then funnel it into jQuery Cycle 2. The modal trigger fired a series of events: acquire the slide data, write the slide data to the modal in the DOM, reinit jQuery 2 and finally show the modal. Closing the modal did the inverse, hiding the modal, destroying the jQuery Cycle 2 instance and destroying the data that had been written into the DOM.

See the Pen Loading multiple slides from a Data-attribute into jQuery Cycle 2 by Greg Gant (@fuzzywalrus) on CodePen.

What made this project work was the extremely tight team, consisting of Christa (Project Manager), Dan (Lead Back End Developer), Mike (tech lead), Adam (Designer), and Daemon (Creative Lead), and myself as the lead front end developer. Due to the timeline, all interaction animation design fell on my shoulders.

See the Pen 1 pane Simple 2D transform Overlay Hover Animation by Greg Gant (@fuzzywalrus) on CodePen.

The Future

With a narrow dev window, we were able to accomplish what at times that seemed the near impossible: creating a site that houses thousands of images, hundreds of articles all across multiple templates. We launched on time to meet the quarterly earnings deadline. We also landed a service agreement retainer contract and have continually improved the website since.