Eoin Thomas O’Hehir

UX Engineer

◀ Back

AOL.com Navigation

A complete rebuild

In late 2016, I was tasked with executing a dramatic overhaul of the site navigation across all of AOL. This was a big project; not just because of how complex it was, but because I was changing a reusable component used on every single page across the website.

The designs were already completed and signed off before they were passed to me. The navigation needed to work seamlessly with all pages, without breaking any existing designs. The new design did not add any new features, but I felt adding some slick animations on top of the clean new look would enhance the experience.

Screenshot of AOL.com website on desktop view

Mobile First, Mobile Best

The biggest change on the site navigation was in mobile. Instead of sliding over a navigation bar from the left side and hiding the page under a transparent curtain, the new navigation completely took over the main page, still allowing the user to access their account information and making links much bigger and easier to tap.

This is where the animation really shines through. Instead of hiding and showing the navigation background with its display property, I used carefully-timed z-index and opacity transitions to pop the navigation above page content and fade it in, resulting in a smooth, jitter-free animation.

iPhone with AOL Navigation displayed on it
Screenshot of a user’s results from the AOL Met Gala Bracket

The Challenges

Making this work on all pages meant I needed to keep the entire website in mind, because while most pages used the same template and styles, there were a number of edge cases to be accounted for.

The obvious ones were pages that used different background colors, especially the pages using black instead of white. I had to keep the background-color of the navigation bar consistent with the page background, and made sure that the blue for the mobile navigation menu still shone through.

Maintaining Functionality

Some old features were taken out of the new design only to be put back, due to user demand. One of those features was including the local weather on desktop.

The weather component used in the navigation needed to show the same results as the other location-based components on the page. Utilizing the commonly available API maintained by my colleagues, I was able to show consistent results even though the navigation and page components were in completely separate codebases.

Small image showing weather module from AOL.com navigation

How I could have done it better

I originally kept all the navigation-based code to three main files: one for the markup, one for the styles, and one for the scripts. It initially made working on the navigation simple. However, as I kept working on this component and maintaining it after it was deployed, it became frustrating to sift through hundreds of lines of code just to get to the one part I needed to change.

Splitting up this large component into smaller components, like separating the header navigation bar from the full mobile navigation menu, would have kept things much more logically separated. It would allow myself and other developers to go exactly where we need to instead of having to needlessly scroll through those giant files.

What I learned

When working on components that are reused this often on a large website, making sure it works is just the first step. Building it in a way so that other developers find it easy to understand, maintain, and build upon is just as important.

See more projects

AOL Navigation


Met Gala Bracket

Trump Campaign Promises

One-A-Day Tumblr Theme

Custom Portfolios