Designing and building a UI that works for all of your users, in all contexts

We recently released an update to our product UI, and we wanted to take a moment to share with you one of its cooler features. You’re probably already familiar with the changes to our navigation system, and with the general visual overhaul. But you may not have discovered the best stealth feature…

Design failure

The old site was built on a liquid grid, meaning that the site would grow or shrink as you scaled your browser window. However, the liquid grid had limits, which made it less than ideal for anything with a small screen — like a smart phone, tablet or netbook. Coincidentally, almost none of our users looked at our site with a smart phone or tablet. Why? It’s not because our users don’t have such devices — quite the opposite, in fact. Our users are as savvy as they come. It turned out they weren’t using their smart phones because our site was completely useless in that context.

On the opposite side, users who had our site open on kiosk-style monitors in their offices or ops centers were also disappointed; the site didn’t scale up particularly well. So we were failing users on small and large screens alike.

Fundamentally, this was a failure of our site’s design.

Design success: responsiveness

Our business is all about helping organizations optimize the web experience for their end users yet, our site was offering a less than optimal experience for our own users. In approaching the redesign, we wanted to improve the user experience for all of our customers. But how? Responsive design gives us a methodology. To quote Ethan Marcotte, noted author and speaker on web design and development:

Responsive design is not about “designing for mobile.” But it’s not about “designing for the desktop,” either. Rather, it’s about adopting a more flexible, device-agnostic approach to designing for the web.

To me, this is a win-win situation. Not only can we avoid building two sites — one for mobile, one for desktop — but we can also improve the experience for everyone, on all devices. We win as developers, and our users win too. This mirrors the way New Relic works on product feature development: we always put the users first and foremost when building new capabilities. It was time for our visual design to do the same.

In practice, adopting a responsive approach means that:

  1. We don’t assume much about the user’s screen
  2. We provide a useful experience regardless of the user’s screen size
  3. We put the user back in control of their experience

Our new layout was built to be both fluid and responsive. It scales to the size of the browser window, but also changes what is displayed based on that width. Let’s see how the new responsive design stacks up against the older fluid design.

Large screens

Let’s start by looking at the old layout in large screens. We’ve shrunk the images down to 50% resolution, so if you click through don’t be alarmed at the smaller size.

V2 on a large screenNotice all of the gray on the edges. You’ve hit the maximum width of the layout and exceeded it; the layout isn’t going to be helpful in this situation. Now let’s compare this with our current UI:

V3 on a large screenThis is much more helpful! If you want to use the full screen, go ahead — it’s your call. We’ve gone a step further than this, however. We now have a new “Kiosk mode” available from a link at the bottom of the screen that removes all the navigation elements from the page. Kiosk mode is meant especially for large heads-up displays like this:

V3 on a large screen in kiosk modeEven better! This is great if you use New Relic in your operations center as all of your screen real estate can be given over to seeing the content you want.

Small screens

Several of our engineers have large screens, but use them to tile many windows side-by-side and each window ends up being quite small. Let’s see how the old and current versions of New Relic perform in this kind of environment:
V2 vs V3 on a small screen First, notice that what the old version on the left shows is the same thing as we saw above on the large screen. Same nav, same elements, all in the same positions. Now look at the bottom — V2 has a horizontal scroll bar. Ugh. Horizontal scrolls are sub-optimal, because users frequently don’t realize they’re there, and if they do, there’s usually no easy way to scroll left-to-right. The current version on the right, doesn’t have one. In fact, we’ve made a lot of changes to the page layout:

  1. Font sizes have changed
  2. The nav has moved from the left side to the top
  3. We have linearized the content on the page

The third point is especially interesting. Take a moment to open up the site in a narrow window. All of the page’s structural elements take the full width of the page, so each of them has enough room to show you its content; they stack vertically for easy display. This is especially useful for smart phones where the thumb scroll is such a natural interaction that it’s not a big deal to have so much of the page content “below the fold.”

Speaking of smart phones, let’s see what the older and newer versions look like on an iPhone:


V2 vs V3 on an iPhoneThese two screenshots were taken with the Apple iPhone simulator. Notice how the old version looks the same as it does in a standard browser. Nothing has changed. As a consequence, the text is too small be easily legible. The new UI has adjusted a bit more to its context, and you can really see what’s going on. Especially on the newer Retina displays.

Don’t forget about printing

I won’t show you examples here, but the new UI has a useful print stylesheet, so you can print out our pages and get something useful. The old version really didn’t print well at all. This is yet another situation that is important to account for in designing a site that works for your users in all contexts.

More info

In addition to the article that started it all, there’s a great article at Smashing Magazine with lots more examples, and a gallery of sites employing this strategy. There are plenty more articles out there as well. And you can always look at our CSS to get examples of how our media queries are built.

Brent Miller is a principal engineer & architect for New Relic. He traded in his training as a botanist to become a frontend engineer, and has spent the past decade building UIs that are easy to manage and helping the engineers around him become better at what they do. View posts by .

Interested in writing for New Relic Blog? Send us a pitch!