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.
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.
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.
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.
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.
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.