clock menu more-arrow no yes

Filed under:

Re-inventing the Polybar

Written by Tyson Whiting, David Zhou & Jake Lear

When Polygon.com launched, the original design of the main navigation bar - nicknamed the Polybar - presented a unique challenge. After a number of design iterations, front-end prototypes and an 11th-hour consensus just before Polygon’s site launch, we settled on a simple bar with a dropdown menu that contained links to Polygon’s main hubs.

Among other things, the original Polybar included search, user login, and social links for Twitter, Facebook and YouTube.

As the site began to grow, we realized that this navigation was limited, and not easily expanded. The editorial team was creating a lot of great content that wasn’t being surfaced on the Polybar. For example, feature series like Human Angle and Polygon’s daily recap show, Speed Run, were difficult to find once they’d fallen off the homepage.

We suspected we could do better. And after investigating performance metrics in our analytics data for the Polybar, we knew we had to do better.

Analytics

We had added Google Analytics event trackers to the Polybar shortly after launch. And as we accumulated data, trends supported our suspicions that the links in the dropdown nav were not performing the way we had hoped; fewer than 1% of users clicked any of the links in that dropdown. We attributed this to a couple of factors: the primary hub links were hidden from view unless the user hovered the site logo, and the links that we did offer accurately representing the breadth of content on the site.

In short, we weren’t making it easy for users to find content they wanted.

The Redesign

Our goals with the redesign were fairly straightforward: make it easier for users to find what they want, and provide a more robust interface for adding new content as needed. We needed a strong way to guide users through everything great Polygon has to offer as the site grows.

The challenge when you present more information to the user is to keep the experience both beautiful and functional. Additional content shouldn’t overwhelm, but needs to remain easily discoverable. To that end, we created a hover dropdown to push content to the forefront without making it feel like each menu is a can of sardines exploding at the seams.

As you can see we sketch all over the doors and walls of our little office. We kept these drawings up for most of the process; you never know when you need to look back and pull from the good parts of a bad sketch.

And there was a lot of sketching, as we worked to find the right organizational balance. It was a struggle to keep things from looking just like a standard dropdown — visual flotsam that savvy eyes have been trained to ignore. We wanted the Polybar dropdowns to act as starting points, miniature hubs that would sample of all the content that exists on Polygon. We landed on a aesthetic leaning on large thumbnails with high fidelity imagery, extending the UI found on our hub and article pages,.

In our recent article redesign, one seemingly minor addition that had a big impact was the social bar under the lead image. On each article, users have the opportunity to like Polygon on Facebook and follow Polygon on Twitter and Google Plus. These links previously existed in the main navigation, but they performed significantly better once added to the article page (to the tune of 10,000 new Twitter followers and 8,000 new Facebook likes). Because of this, we felt comfortable removing these links from the main navigation to free up real estate for more content.

Front End

From a front-end development standpoint, the new navigation is significantly more complex than the old one. Where the old nav was one of the simplest things on the site to make responsive, the new nav is one of the more complex features in terms of adjusting for different breakpoints.

Over the last year, Vox Product’s front end devs finalized our style guide for markup and stylesheets, based around SMACSS. In addition to crafting of markup and styles, this navigation project included a rewrite of everything in a new, less-bloated structure. In the initial buildout of Polygon, we used a lot of deep nesting in our SASS to create specific selectors. As a result, our final compiled CSS was much larger than necessary, including slow, overly specific selectors.

Here’s an especially heinous example of some of the styles from the old Polybar:


#nav_social {   float: right;   margin-right: 50px;  
  & > ul {     position: relative;     border: none;  
    & > li {       display: inline-block;       padding: 0 10px;       font-size: 16px;  
      &.fb {  
        .fb-like span, .fb-like iframe {           min-height: 20px;           min-width: 74px;         }  
        & > a {  
          &:before {             background: url(/images/polygon/sprites/icons.png) no-repeat -7px -108px;             content: "";             display: inline-block;             width: 22px;             height: 36px;             position: relative;             top: 10px;  
            @media             only screen and (-webkit-min-device-pixel-ratio: 2),             only screen and (   min--moz-device-pixel-ratio: 2),             only screen and (     -o-min-device-pixel-ratio: 2/1) {               background-image: url(/images/polygon/sprites/icons@2x.png);               background-size: 108px 1043px;             }           }         }       }     }   }

Our new best practices helps cut down on bloat and make our selectors more efficient. We define a module class name for the top level component, in this case “.m-site-nav,” where M stands for module and ‘site nav’ is the component name. From there, we build explicit classes for each item. This way, we don’t need to worry about nesting or selector depth getting out of control, and we use extends and includes to pull in other styles or functionality if need be.

In the following example you can see how explicit selectors let us do away with nasty nesting:



$m : '.m-site-nav';  
#{$m} {   @extend .clearfix;   @extend .-font-gotham;   position: relative;   text-transform: uppercase;   width: 100%;   z-index: 35;   height: $sticky_nav_height;   background: #fff;   border-bottom: 1px solid #CCC;   &.pinned {     position: fixed;     top: 0;   }   @media(max-width: $break_medium_small) {     position: static;   } }
  #{$m}__wrapper {   border: 1px solid #ddd;   border-width: 0 1px;   height: $sticky_nav_height; }
  #{$m}__loader {   @include image-replacement(30px, 30px, "/images/polygon/loader-small.gif");   height: 50px;   background-position: center center;   margin: 0 auto; }

Beyond this style refactor, the navigation redesign provided all the regular challenges that come with responsive features. We use percentage based widths, and drop items off at specific breakpoints. We actually duplicate markup for the mobile drawer-style menu, but since all content in the desktop version is lazy loaded, the performance impact and extra page weight is minimal.

Back End / Lazy Loading

Throughout the redesign process we were adamant that the new Polybar should not be any slower than the previous version. Extra content is good, but not at the cost of a more sluggish experience. After some experimentation, we decided that lazy-loading every dropdown at runtime was an easy and relatively robust way to reach that goal.

Lazy-loading is the practice of not loading an asset until it is needed (hence, the “lazy” descriptor). On Polygon, we already lazy load images - pictures down past the visible portion of the window are not loaded until they are scrolled into view.

The new Polybar takes a similar approach, not loading dropdowns until a user hovers over a menu item. This cuts down on the amount of data and markup going into the dropdown considerably. Though the fully loaded navigation would contain over thirty entries — each with its own set of images and text — lazy loading cuts that down to zero. Content is loaded into the dropdowns as needed. If a user never hovers over the Polybar, that additional content is never fetched.

Success?

The new Polybar has been in place for a relatively short amount of time, but we’ve already seen evidence of significantly more users interacting with the main navigation items. Our old navigation saw about 0.5% of users interacting with the dropdown, where now we have 14% of users doing some sort of interaction with the dropdown menus.

Additionally, we are able to surface much more of the great content that Polygon is producing, and our navigation has room to grow.

We’re still working out some of the kinks, but we hope that this new Polybar will carry the site for a long time to come, and help users find all the great content that Polygon offers.